自动程序的崛起与优势 (自动程序的崛起与发展)

自动程序的崛起与发展

一、引言

随着科技的飞速发展，自动程序已成为当今信息化社会的重要组成部分。
从智能家居到工业自动化，从人工智能到云计算，自动程序的应用领域日益广泛。
本文将探讨自动程序的崛起背景、发展现状以及其优势，以期对自动程序有更深入的了解。

二、自动程序的崛起背景

自动程序的出现，离不开计算机技术的不断进步。
自计算机诞生以来，人们一直在寻求让计算机自动化完成任务的方法。
随着算法、数据结构、操作系统等计算机技术的不断发展，自动程序逐渐成为现实。
大数据、云计算、物联网等技术的发展，为自动程序的广泛应用提供了有力支持。

三、自动程序的发展现状

1. 市场规模及增长趋势

近年来，自动程序的市场规模不断扩大，呈现出快速增长的态势。
随着人工智能技术的不断发展，自动程序在各个领域的应用逐渐普及。
据相关数据显示，自动程序市场规模逐年增长，预计未来几年将持续保持高速增长。

2. 核心技术进展

自动程序的核心技术包括自动化开发、机器学习、深度学习等。
随着技术的不断进步，自动程序的开发效率不断提高，应用范围不断扩大。
目前，自动程序已广泛应用于智能制造、智能家居、金融科技、医疗等领域。

3. 主要应用场景

（1）智能制造：自动程序在智能制造领域的应用，可大幅提高生产效率，降低生产成本。
例如，智能工厂中的机器手臂、自动化流水线等。

（2）智能家居：自动程序通过智能家居设备实现家居环境的智能化管理，提高生活品质。
例如，智能音箱、智能照明等。

（3）金融科技：自动程序在金融行业的应用，可实现交易自动化、风险控制等功能，提高金融业务的效率。

（4）医疗领域：自动程序在医疗领域的应用，可辅助医生进行疾病诊断、手术辅助等，提高医疗水平。

四、自动程序的优势

1. 提高效率

自动程序能够自动化完成一系列任务，大幅提高生产效率。
相较于传统的人工操作，自动程序具有更高的准确性和效率，能够降低人力成本，提高生产效益。

2. 降低成本

自动程序的应用可以降低企业的运营成本。
通过自动化生产，企业可以减少人力投入，降低人力成本。
同时，自动程序还可以降低物料成本，通过优化生产流程，减少物料浪费。

3. 提升质量

自动程序具有高度的准确性和一致性，可以确保产品质量。
相较于人工操作，自动程序能够避免人为错误，提高产品的合格率。

4. 促进创新

自动程序为企业创新提供了有力支持。
通过自动化生产，企业可以更加专注于产品研发和创新，提高市场竞争力。
同时，自动程序还可以帮助企业开拓新的应用领域，实现跨界发展。

5. 应对复杂环境

自动程序能够应对复杂的生产环境，如在高温、高压、高辐射等环境下完成任务。
这些环境对人工操作来说极为危险，而自动程序可以确保安全、高效地完成生产任务。

五、结语

自动程序的崛起与发展是科技进步的必然结果。
其在提高效率、降低成本、提升质量、促进创新以及应对复杂环境等方面具有显著优势。
随着技术的不断进步，自动程序的应用领域将越来越广泛，对社会发展产生深远影响。

---

电脑软件的发展史？

电脑软件的发展史

第一代软件（1946－1953）

第一代软件是用机器语言编写的，机器语言是内置在计算机电路中的指令，由0和1组成。

第二代软件（1954－1964）

当硬件变得更强大时，就需要更强大的软件工具使计算机得到更有效地使用。 汇编语言向正确的方向前进了一大步，但是程序员还是必须记住很多汇编指令。

第三代软件（1965－1970）

在这个时期，由于用集成电路取代了晶体管，处理器的运算速度得到了大幅度的提高，处理器在等待运算器准备下一个作业时，无所事事。 因此需要编写一种程序，使所有计算机资源处于计算机的控制中，这种程序就是操作系统。

第四代软件（1971－1989）

20世纪70年代出现了结构化程序设计技术，Pascal语言和Modula-2语言都是采用结构化程序设计规则制定的，Basic这种为第三代计算机设计的语言也被升级为具有结构化的版本，此外，还出现了灵活且功能强大的C语言。

第五代软件（1990－至今）

第五代软件中有三个著名事件：在计算机软件业具有主导地位的Microsoft公司的崛起、面向对象的程序设计方法的出现以及万维网（World Wide Web）的普及。

扩展资料

依据许可方式的不同，大致可将软件区分为几类：

1、专属软件：

此类授权通常不允许用户随意的复制、研究、修改或散布该软件。 违反此类授权通常会有严重的法律责任。 传统的商业软件公司会采用此类授权，例如微软的Windows和办公软件。 专属软件的源码通常被公司视为私有财产而予以严密的保护。

2、自由软件：

此类授权正好与专属软件相反，赋予用户复制、研究、修改和散布该软件的权利，并提供源码供用户自由使用，仅给予些许的其它限制。 以Linux、Firefox 和OpenOffice 可做为此类软件的代表。

3、共享软件：

通常可免费的取得并使用其试用版，但在功能或使用期间上受到限制。 开发者会鼓励用户付费以取得功能完整的商业版本。 根据共享软件作者的授权，用户可以从各种渠道免费得到它的拷贝，也可以自由传播它。

4、免费软件：

可免费取得和转载，但并不提供源码，也无法修改。

5、公共软件：

原作者已放弃权利，著作权过期，或作者已经不可考究的软件。 使用上无任何限制。

Delphi7.0程序设计语言的优点和缺点

推荐你一篇不错的文章，或许对你有些帮助。 VC和Delphi作为开发平台，很重要的一点就是提供了一个无所不包的应用框架：VC的MFC和Delphi的VCL。 MFC是用C++写的，VCL是用Object Pascal写的。 当然，我们都知道，C++的使用范围比Object Pascal广得多，移植性也好得多。 这本来是优点，但很有意思的是，正因为如此，微软写MFC时必须考虑最大限度减少对语言本身的改动，而把功夫下在源代码级，以便能尽可能支持ANSI等标准，结果导致MFC的封装复杂而不直观。 (尤其是它对消息的封装，下文还会提到)。 太多的宏定义和含义模糊且自动生成、不得改动的注释使MFC乃至VC让很多新手望而生畏，不敢下水深入学习。 而Object Pascal几乎是Inprise专用的，不必考虑标准问题，因此Inprise写VCL时就把全部精力放在了结构与性能上，结果语言与框架的磨合程度非常好。 VCL框架的结构清晰，VCL代码的可读性非常好。 许多人说Delphi比较容易上手，也是这个缘故。 天下没有白吃的午餐。 你要工业标准吗？你要可移植性吗(关于可移植性和兼容性，下文会详细比较)？那么请面对MFC的天书级代码吧。 编译和连接：The Need For Speed不同的语言带来的另一个不同是，编译和连接的速度的不同，以及执行速度的不同。 Delphi的编译和连接速度，毫不夸张地说，比VC快几十倍。 即使把VC的Incremental Link选项打开，Delphi的编译和连接速度仍比VC快好几倍。 并不是说微软的编译器不行，这是由C++的复杂性决定的。 模板的处理、预处理和宏的展开都是很费时的。 前文不是提到Object Pascal没有模板、预处理和宏吗？这本来是缺点，但带来的一个好处就是编译速度极快。 至于编译完的二进制代码，在打开相同的优化选项的情况下，Delphi和VC执行速度并没有太大的差别。 为了克服编译的速度问题，C++编译器一般需要增强的连接器和预处理机制。 但是预处理机制仍然存在若干问题：1）程序调试的断点行可能和代码行不同；2）没有将最新的代码信息综合进去；3）容易产生错误的逻辑；4）因为读错文件头而很容易产生类似Unexpected End of File的错误。 两个编译器有个共同点是都能识别无用的死代码，比如一个没有用的函数等等。 编译后的程序将不包含这些多余的信息。 Delphi在这方面作得更加出色。 它可以让你在编辑器中可视化地提示出那行代码是活的、那行代码是死的。 这样你就能整理出最精简的代码。 Delphi在编译后将在左边显示一个小蓝点表示这行代码是活的。 Visual C++做不到这点。 Delphi编译后可执行文件至少有200K（如果不使用VCL，仅仅使用WinAPI，文件的大小将大大缩小）但是Visual C++编程使用MFC编译后的可执行文件通常只有几十K，主要是因为微软已经将系统运行库包含在Windows系统了（Borland公司曾经和微软协商这个接口，但是微软利用操作系统的优势不愿意公开）。 同样道理，使用BDE开发的的数据库程序必须附带3-5M的额外系统文件，也是非常不协调的。 非常有趣的是，Delphi能够使用由C++ Builder创建的的OBJ文件，但是使用上受很大的局限性。 最后，Visual C++的编译和连接时的错误信息比Delphi要详细和具体的多。 特别是使用ATL开发更加如此。 应用框架：MFC？有KFC流行吗？应用程序框架(Application Frame)，有时也称为对象框架。 Visual C++采用的框架是MFC。 MFC不仅仅是人们通常理解的一个类库(同样，Delphi的VCL也不仅仅是一个控件库，尽管它的名字叫可视控件库)。 你如果选择了MFC，也就选择了一种程序结构，一种编程风格。 MFC早在Windows 3.x的时代就出现了，那时的Visual C++还是16位的。 经过这些年的不断补充和完善，MFC已经十分成熟。 但由于原型出现得比较早，MFC相比于VCL落后了一个时代。 尽管微软对MFC的更新没有停止，我也经常读到只要Windows不过时，MFC就不会过时之类观点的文章，但就象Inprise(原Borland)的OWL框架的淡出一样，MFC的淡出也是早晚的事。 其实MFC是和OWL同一个时代的产物。 OWL已经不在了，MFC怎能不居安思危呢？如果MFC青春永驻，微软的开发人员也不会私自开发出基于ATL的WTL呀。 当然，WTL的地位不能和MFC比，它并不是微软官方支持的框架，封装的功能也相当有限。 但至少也反衬出了MFC存在的不足。 我们以为，最能体现一个应用程序框架的先进性的是它的委托模型，即对Windows消息的封装机制。 对Windows API的封装就不用说了吧。 大同小异，也没什么技术含量。 如果高兴，你也可以自己写一个类库来封装。 但对Windows消息驱动机制的封装就不是那么容易的了。 最自然的封装方式是采用虚成员函数。 如果要响应某个消息就重载相应的虚函数。 但出乎我的意料，MFC采用的是古老的宏定义方法。 用宏定义方法的好处是省去了虚函数VTable的系统开销(由于Windows的消息种类很多，开销不算太小)。 不过带来的缺点就是映射不太直观。 对于MFC，则是太不直观了。 它的消息映射代码虽然是可见的，但劝君莫碰。 好在VC的ClassWizard可以自动生成消息映射代码，使用起来还算方便。 但和VCL的委托模型相比，MFC的映射方法就显得太落后了。 而Delphi的Object Pascal因为没有标准负担，语言引入了组件、事件处理、属性等新特性。 由于功夫做在编译器级，生成的源代码就显得十分简洁。 似乎VC是让框架迁就语言，而Delphi是让语言迁就框架。 我想举一个对字符串操作的封装的例子来说明MFC和VCL的优缺点。 在MFC中，CStringList类有加入、获取、删除等功能，但VCL的TStringList类除了上述功能还有排序、从逗号分隔的字串读入、流输入输出等功能。 但同样的字符串替换功能，VCL的StringReplace要比MFC的CString::Replace慢2－3倍。 总的来说，VCL的封装比MFC更为高层，更为抽象，但不可避免地带来的问题是某些部分执行效率比MFC略低。 这就象低级语言(如汇编)的执行效率比高级语言(如Basic)高，但编程效率较低。 鱼和熊掌不可兼得嘛。 VCL比之MFC的另一优点是对异常处理的支持，而一大缺点是对多线程支持差。 VCL的大部分都不是针对多线程优化的。 虽说VCL提供了简化多线程操作的类，但只是工作者线程(worker threads)使用起来比较简单。 如果线程要和界面打交道的话事情就变得麻烦了，因为除了应用程序的主线程，任何线程不能访问任何可视的VCL部件。 你不得不使用Synchronize方法等待主线程处理它的消息，然后在主线程中访问VCL部件。 而MFC就没有这样的限制。 稳定性与完善程度：VC是老大哥VC要比Delphi稳定和完善。 VC的发展历史比Delphi长，微软的总体实力比Inprise强。 VC的框架MFC经历了那么多年的发展和完善，功能非常全面，而且十分稳定，bug很少。 其中你可能遇到的bug也更少。 而且有第三方的专门工具帮助你避开这些bug。 如此规模的一个类库，能做到这一点不容易。 不要小看了这一点，很多专业程序员就是为这个选择VC的。 因为尽管VCL比MFC的抽象程度高，封装较为高层，但由此带来的开发效率的提高对高手来说毕竟是有限的。 而如果你遇到一个怪问题，调试了半天，发现不是你的代码有错，而是VCL的bug，你作何感想？虽说遇到这类问题的可能性很小，但对VCL的形象的影响可不小。 Delphi的IDE太占资源，启动速度太慢，和某些显卡驱动程序冲突，VCL中有bug，调试器不够健壮，对不稳定的第三方控件没有防护措施 …… 问题多多，在这方面Delphi不如VC。 希望Inprise能更上一层楼。 顺便说一下，我们在网上看到有些人极言Delphi的不稳定，说几分钟出现20多次非法操作。 Delphi的确不如Visual C++稳定，但也不至于如此呀。 我估计是那位朋友的Delphi装了某些有问题的第三方控件，导致了Delphi的频频出错。 不妨卸下那些控件试试？可移植性：立足现实，放眼未来Inprise正在开发Delphi的Linux版本，代号为Kylix。 也许通过Kylix，用VCL构架编写的Windows程序向Linux移植成为可能。 但这只是可能。 因为在目前Inprise的兼容性工作做得并不好。 低版本的Delphi不能使用高版本的VCL组件，而高版本的Delphi竟然不能使用低版本的VCL组件。 真是岂有此理，我们很少看见软件有不向下二进制兼容的。 如果Windows 98不能运行95的程序，Windows 95不能运行3.x的程序，Win 3.x不能运行DOS程序，你还会用Windows吗？如果Windows 95的程序必须经过重新编译才能在98下运行，98会卖得那么好吗？同门兄弟C++Builder和Delphi也不能互相使用对方的组件，甚至同一套VCL库的文件名也不一样。 所以一个组件有for D1/D2/D3/D4/D5/C1/C3/C4/C5这些不同版本是常有的事，而且随着Delphi和C++Builder版本的升级可能还会增加。 希望Inprise能先解决同门兄弟的兼容性问题。 而微软的VC就没有这类问题。 MFC1.0的程序也可以毫无障碍地在VC6.0下编译通过。 集成界面：宏观与微观就大处说，VC的集成界面是不如Delphi的。 Delphi仅仅一个Object Inspector就可以将VC的一堆Wizards比下去，何况它还有Code Explorer、ToDo List等。 但从小处，又可以看出Delphi的不成熟。 比如自动完成功能的智能化程度和提示详细程度不如VC，响应速度也没有VC快。 Visual C++所带的MSDN是一部开发者的百科全书，信息庞大，查询方便，这方面比Delphi更专业。 很多帮助项都有源程序示范。 Delphi的OpenTools是完全面向第三方的开放系统，开发者可以修改很多Borland公司自身的功能，从IDE的可扩充性上说Delphi更好。 调试：细微之处见真功Visual C++和Delphi的调试功能都非常强大，同时都具有单步可视化调试、断点跟踪、运行时改变变量、鼠标指向可以得到变量值等等功能。 对DLL的输入输出也能方便的管理，能够进行源码级别的调试。 相对而言，Visual C++能够更加方便地看到变量的变化情况，这包括对结构可以展开成数据树，从而了解每一个变量的值，每一步调试，变化了的变量会加红，从而使调试更加方便。 另外，Visual C++的块内存察看比Delphi也要方便。 当然，Delphi也有很多体贴的细微之处，比如在线程调试的时候，Delphi能够很方便地察看线程的变化，Visual C++却必须要弹出一个模式对话框。 数据库开发：Delphi一枝独秀数据库支持是Delphi的强项。 这主要体现在Delphi与BDE的无缝集成，以及Delphi提供的那一大堆现成的数据库操作控件。 这是VC望尘莫及的。 目前Delphi支持BDE、ADO、InterBase三种数据库访问方式。 所有的方式都能拖拉到应用程序中实现可视化操作。 正是因为Delphi对数据库类的包装，使得用户操作数据库不像在Visual C++中必须从开始到最后都要干预。 明显地提高了开发速度。 Delphi中使用WebBroker控件还能很方便地构造出基于数据库的Web页面，通过HTML管理Web数据库。 Visual C++访问数据主要通过ADO和OLEDB，很多ActiveX控件也能添加数据库功能。 但是没有像Paradox这样的桌面数据库，Access相对功能太弱了。 也许SQL Server是不错的选择。 COM：新技术的力量COM是组件对象模型的缩写。 它是OLE和ActiveX技术的基础，COM定义了一组API和一个二进制标准，让不同的编程语言、不同平台的彼此独立的对象相互进行通讯。 COM是Microsoft制订的行业标准。 但Delphi也为COM提供了强大的语言支持。 支持接口、variant、宽字符串功能。 这些对COM的封装确实比C++更方便。 比如在C++（没有类框架）进行COM编程时，变体定义为oaidl.h文件中的VARIANT结构。 要处理变体，必须手工调整中VariantXXXX() API函数对其进行初始化和管理，如VariantInit()、VariantCopy()、VariantClear()等等。 Visual C++实现COM编程有一种特殊的方法就是使用ATL。 ATL使用Visual C++特有的多重继承来实现COM接口。 虽然不见得实现COM服务和控制更容易，但是ATL和最新COM技术的接口，基于模板的构造都比Delphi强。 ATL更有利于建立小巧、快捷的COM组件程序。 按目前通用的观点，Visual C++应用到COM服务程序更有优势，Delphi应用到COM组件程序更合适。 昨天，今天，明天技术的进步在很多时候是此消彼长的。 当初Borland的Turbo C和Borland C++几乎是C/C++程序员唯一的选择。 微软的Quick C(现在还有人知道这个产品吗？)和Microsoft C/C++从来也没有成为过主流。 但Borland C++又流行了多少年呢？不久就被新崛起的Microsoft Visual C/C++压下去了。 于是Inprise(原Borland)拣起了当年Turbo Pascal和Borland Pascal的辉煌(事实上Borland的成名作就是第一个Pascal编译器)，全力推出了Delphi。 Delphi当初推出时被称为VB杀手，但VB现在仍然活得挺好。 毕竟微软是靠Basic起家的嘛，VB不是那么容易被打败的。 Inprise想了想不和VB争了，使用Delphi的IDE和VCL配上C++语言，推出了C++Builder，又向Visual C++的市场发起了夹攻。 C++Builder似乎是个不错的折衷选择了？再仔细想想！C++Builder的优点Delphi都有，但Delphi的优点C++Builder未必有。 比如C++Builder的编译速度比VC还慢，哪能和Delphi比？而且因为VCL是Object Pascal写的，C++语言和VCL磨合得并不好。 C++Builder的bug比Delphi还多，甚至Sample代码中还有错。 VCL的部分功能不能使用，要靠嵌入pascal代码访问。 C++Builder可用的第三方控件远没有Delphi多。 唉，真是金无足赤。 Microsoft和Inprise，谁会笑在最后呢？鱼和熊掌：艰难的选择选择一个开发工具依赖于很多不同的因素，每个人都能因为某种语言的某个缺陷而放弃学习或使用这种语言。 任何程序员都希望自己喜欢的工具能达到理想的境界，通过上面不完善的比较，我想大家都有自己的看法。 我们认为影响大家选择开发语言的因素主要包括： 1） 哪门语言更容易入门？ 学习一种语言需要投入大量的时间和精力。 开发程序的开发成本是值得考虑的现实。 一个熟练的Delphi程序员和一个熟练的VC程序员工作效率是一样的。 但是，成为熟练的程序员必须很快掌握一门语言的技巧。 不幸的是，目前熟练的Visual C++程序员是十里挑一。 相对而言，Delphi更适合初学者。 2） 哪门语言有更多可继承的代码？ 语言代码的可重用性是加快开发效率明显方面，从早期的过程、函数到现在的组件技术都是朝这个目标在奋斗。 这两种语言对代码重用的理解是不一样的，Delphi主要通过VCL控件来实现代码重用，Visual C++实现起来就比较复杂。 3） 语言自身的本性。 就技术(主要指应用框架)来说，Delphi目前领先于Visual C++。 但稳定性和健壮性的不足又让我对Inprise想说爱你不容易。 而VC尽管发展到今日已十分完善，但MFC框架已是明日黄花了。 如果不使用MFC，目前又没有合适的替代品。 根据你的需要和实际情况做选择吧。 实际上Visual C++和Delphi也不是简单竞争关系。 它们在许多领域并不重叠，甚至是互补的。 到底怎样取舍，要根据你的项目特性决定。 如果你开发系统底层的东西，需要极好的兼容性和稳定性，选Visual C++吧。 你可以只调用Windows的各种API，不用MFC。 如果你写传统的Windows桌面应用程序，Visual C++的MFC框架是正统的选择；如果界面部分占这个应用程序代码比例较大的话，或者Delphi中有相关功能的控件的话，Delphi是事半功倍的选择。 如果你为企业开发数据库、信息管理系统等高层应用(高层是相对于低层/底层而言的，不是说技术高级或低级)，而且有比较紧的期限限制，选Delphi比较好。 如果你熟悉的语言是Object Pascal，又不打算学复杂的C++，那么Delphi几乎是唯一的选择。 传统的观点是：Delphi适合编写Internet/Intranet、表格制图、数据库操作、高级用户界面等等。 Visual C++适合编写设备驱动、COM服务程序、科学计算、控制台（console）程序、WinCE的应用和一些小的工具等等。 应用范围的不同要求好的程序员同时精通这两门语言。 4） 语言的前景和可扩充性。 Delphi是Inprise的旗舰产品之一，前景应当还是比较乐观的，而且Inprise已经在向Linux进军了，而微软还迟迟没有动作。 遗憾的是，Inprise公司Delphi的创始人已经跳槽到微软去主持Visual J++和C#项目了。 但愿对Inprise冲击不会太大。 微软的Visual C++的前景又怎样呢？Visual Studio 7.0就要推出了。 这一版本将加强网络开发的特性。 看来微软虽然被判解体，开发实力可是一点没打折扣。 另外，虽说MFC已稍显落后，但不是说它不值得学。 事实上，不学MFC就等于没学VC。 利用MFC框架开发程序仍然是目前开发桌面应用的主流模式，而且还会保持相当长的时间。 微软公司CEO史蒂夫·巴尔默(Steve Ballmer)曾说，流行还得等2－3年。 那么，MFC至少还有2－3年的生命空间。 在技术日新月异的IT界，2－3年实在是很长一段时间了。 好好把握吧。 即使你不使用MFC框架，花点时间看一下MFC的封装机制对你熟悉C++的OOP机制和Windows底层功能也是很有好处的。 而VCL的源代码是Object Pascal的，对C/C++程序员就没有这个额外的作用了。

程序员的工资为什么那么高

每个行业的工资是市场决定的。 得分析需求与供给。

供给：

程序员并不多。 据说中国也只有200万会写程序的人（占人口0.14%）。 相当少。

另外，印度270万程序员（最多的），也只占人口0.2%的样子。

我们先从西方国家的角度出发吧。 虽然和中国印度不一样，但也有很大的参考价值。

美国的Tech行业（包括IT在内）工作人员达到700万；占人口的2%以上。

英国类似，160万员工，也占到2.4%。 其它西欧国家应该都是差不多的比例。

不过拿整个行业来对比不恰当。 因为高科技行业其中只有一小部分人是搞程序的。 美国专业从事软件程序的人口呢，好像只有102万（根据2010年的人口普查）；0.3%。

另外，在美国的职业排行中，程序员在所有职业当中人口数量排行第三十，还少于：

律师职业，104万；金融资产管理，110万；大学老师，130万

如果觉得金融和律师工资高很合理，那程序员工资高也是合理的。

话说，软件行业还详细分类，分各种语言各种平台各种特殊要求。 编程语言的话；熟悉Java到专业程度的程序员只有其中30%。 Python估计20%。 C不到10%。 像Golang之类的小众语言，1%都没有。 （或许可以参考一下github上的用户数据）。

我们假设伦敦只有0.3%的人是写程序到专业程度的，那就是四万人左右。 如果伦敦一家公司必须招Golang经验的人，能选择的程序员可能只有三四百人的范围了。 如果再要求人家Python和Golang都会，那可能少到只有50个人选是合适的。 随便看看一家科技公司的招聘要求，都会有好几个乱七八糟的，比如这语言那语言、什么SQL啊、Linux啊、机器学习啊、云端计算啊。 。 。 每家公司要求也都不一样。 真能完全符合他们所有要求的人可能只有几个甚至根本不存在。 能找到满足两三个要求的人已经算很不错了。

其它行业没这么麻烦，一个职位总是有很多人都能胜任的。 选择多了，公司就有条件把工资压低之类的。 但是在程序招聘方面，谈工资的权利在程序员手里，因为对方没有选择。 程序员本来那么稀有，非常适合要求的程序员更是稀有之稀有，不能错过。

（在简历上写什么都会的人一抓一大把；但是人家公司也不傻，能看穿。 这些东西到精通的地步都需要好几年的经验。 如果某个程序员真能够精通了其中两三件，又正好符合公司所要的，那价值无上限啊。 稀有度决定一切）

（也有不一样的，一些高科技大公司比如google、facebook，他们不一定要求人家具体会做些什么，因为反正什么类型都会招收一些，而且有耐心培养。 但是人家找的基本是高能力的人，强调problem-solving能力、逻辑清晰、抽象思维、创新思维、有直觉的、等等。 达到这种境界，会什么不会什么都不重要，反正都能很快学会新技能。 但是一般公司没这耐心，没这远见，只想尽快找一位能马上解决特定问题的员工）

（当然也不能说一个程序员的价值取决于他熟悉多少种计算机语言什么的。 请别这样理解。 许多程序员“高阶技能”更是一种训练出来的思考维度，和编程语言无关。 这些维度决定一个人能否有效解决某一类问题。 具体用什么语言并不重要。 不过吧，如果只接触一门编程语言，思维肯定会有些捆绑）

需求：

好吧，伦敦有那么几万个程序员。 假设平均两年换一份工作。 如果市场稳定了（满了），那每个月新空出来的职位应该只有几千个吧？但是伦敦的招聘广告明明每个月都十几万个啊。 而且一年一年越发多。 这只能说明：找不到人了！

很多公司都是招不到程序员的状态。 有些公司一开始很天真，挂一个他们自认为很好招到人的低职位广告，准备四万英镑年资（30多万人民币）。 结果时间过去了几个月，发现过来面试的偶尔几个选手也都不适合，只好把年资提升到六万、八万、十万。 最后终于来了一位程序大牛，非常适合，但是人家被另一个给出15万镑年资的公司给抢了。 结果挂了一年多还在等人；老板的美梦都这样被现实毁灭掉了。

（在伦敦四五万镑年资的程序员当然也有不少，因为这些人总能找到一个能接受他们的公司。 要么公司等得太不耐烦了只能选他们，要么成功装逼就混进去了。 也或许是真找到了最适合的一家了。 。 。 可是意识不到自己的稀有程度，低估自己的价值，有点可惜。 有些人大概工作了几年才会有这种意识吧，然后追求的工资开始飞速涨价。 ）

总体来说，伦敦（以及西方各地）的程序员工资很高是有道理的。 因为需求高于供给高得太多太多了。 其它行业都是公司来选员工。 但是这行业还真是员工来选公司。 这也可能导致各种不公平吧。 许多员工在五十万年资（人民币）的范围混，也有许多员工在百万以上（因为他们找到了自己稀有之处，并且运用了）。 反正平均可能在八十万左右（比伦敦的平均薪资高一倍），但是很少有人的收入在这个平均值，一般是在两个极端。

中国是否处于类似的情况，好像是的。 道理应该也很相似。 如果你在找一千万人，但是只有几百万人能做到，肯定也会这样。 而且其中每一个职位大概只有10－100人能做得好；做得到底好不好又很容易判断出来，薪资差距自然很明显。

程序员收入比其它职业高是事实。 而且一点都不虚。

世界需要很多人来干这些事，能干的人又太少了。

这些程序员只要有几年经验在几家公司，累积掌握到了独特（仅限于自己）的一套技能，总能找到高薪的有价值的工作。 因为他们是稀有动物啊。 只要有一家公司正好非常需要那一套独特的技能，稀有程度已经很明显了。 问题是不止一家认为他们稀有，所以各种抢破头。 因此稀有的高级程序猿可以挑来挑去。 公司竞争抢程序员而不是程序员竞争入公司。

最后讲几句关于未来：

首先，在所有职业当中，程序员是增长得最快的。 大家应该都能看得出来。 很多传统工作类型已经渐渐被取代了。 正是因为程序员把这些工作内容自动化了。 这个趋势肯定会继续下去。

最简单的一例应该是收银员工作。 以前需要好几十个员工来负责收银的超市，现在只需要一两个收银员。 超市里各种越来越先进的自动收银机器。 至少在英国大多超市是这样的吧。 整个人工收银行业在未来可能就不存在了。 哦，还有金融行业现在几乎所有交易都是自动程序操作的。

其实大多行业，迟早都会有类似的淘汰现象发生。 目前，大家不会想到有一天医生会被软件取代。 可是仔细想一想，一个软件能分享和同步全世界所有的医疗数据来做一次诊断，远胜一个人的脑力所能做到的。 律师分析历年来的案例和档案去找出漏洞的能力也可能不如一个软件程序。 其他行业我就不一一说了，以后值得另外好好写一写。

这些变化会远远超过几次工业革命的变化。 软件行业是唯一能坚持得比较长久的。 这些其它行业被自动化软件化也都需要这些程序员来实现和维持。 但是未来几十年内，需求只会越来越大。 与其它行业的工资差距也会越来越极端。

感觉很多非行业的人有一种错觉。 。 。

错认为编程(或Tech)就是很多行业当中的其中一个而已。

我只能呵呵。

几百年前的人也会认为“工业”只不过是一个小行业，因为人不多。 随着科技的发展，工人成了主流，这“工业”开始分成各种各样划分开来的新行业。 后来服务业（白领）又突然发展起来了，分裂成现在大家所熟悉的各种行业。

下一次工作变革就是编程。 它会慢慢形成很多独立行业。 现在已经能看得出来啊，软件行业里面已经有很多不同方向的。 。 。 我干不了A，A干不了B，B干不了C，C又干不了我所做的。 但是我们都是“程序员”。 在以后，我们就不会再说“他是程序员”，而说“他是A”，“他是B”。 因为到以后大多数人都是程序员。 一百年以后，“程序员”这个词就毫无意义了。

（当然也不是永久的；AI之类的也总会取代程序员，最后让软件写软件。 将来下下下一个paradigm是什么我们都猜不到吧，无法想像。 那时可能都没有“工作”这般概念。 但是程序员的崛起作为目前一个大的paradigm shift，这是能确定的哦，毕竟这才是一步一步走向AI必须经过的一段历史）

汉语中的软件与英语中的software。 。 。 含义好像不太一致？我觉得任何程序员写的都可以叫做software，不一定仅限于公开给大众下载用、有界面的应用。 比方说，那些自动化交易程序，或者一些公司给内部开发的特殊功能，或者谷歌背后的搜索引擎后端，或者一辆汽车一台照相机里面的系统。 。 。 甚至一个drone，这些也都是软件吧？？

作为一个收入(可能是)amazon程序员中top%10的程序员， 我来很简单的分析一下一般程序员的心态：