Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

编程的未来

Posted on 10/14/201206/23/2019 by 四火

1 最近在看一本书,加来道雄(Michio Kaku)的《物理学的未来》,第一、第二章是程序员更加关心的,对于下一个 100 年计算机和人工智能未来的预测。想想计算机发展短暂的历史,这些发生了的翻天覆地的变化,似乎都在弹指一挥间。谁的大胆预测可以那么准确?无论如何,书中对其这样几个猜想令我记忆深刻:

  • 因特网眼镜和隐形镜片
  • 无人驾驶汽车
  • 摩尔定律结束
  • 通用翻译器
  • 全息摄影和三维影像
  • 意识识别
  • 有意识情感的机器人
  • 模拟大脑

这是物理学家眼中的世界(另外推荐他的另一本书《平行宇宙》),激动人心;另一方面,我回想起小时候无比痴迷的机器猫,小小四维空间袋,寄托了孩子多少纯真的梦想,有多少神奇的道具已经成为现实……

但是程序员要说的看法,尤其在自己熟知的领域,我们不谈语言的发展和趋势,这些留给专家去做吧——不妨把目光放长远一点,100 年后的程序员,他们都在做怎样的事情?100 年后的编程,会是怎样的一种劳动?

人人都会编程

微博上,有朋友对于 HTML5 实现的 web 操作系统评论道 “断网就是废物一个”,但是他并没有意识到,很快网络就将如同现在的水、电这样一样,是人正常生活不可缺少的基础设施。

类似的,编程,也将是未来人们日常生活的必备技能,如同写字、阅读一样。编程并不非得指写那些非程序员看不懂的奇形怪状的代码。你把衣服放到洗衣机里,设定好水量中等,浸泡 20 分钟,洗涤 20 分钟,漂洗 3 次共 15 分钟,再甩干 3 分钟——这,就是编程,你做的仅仅是按几个按键,把这几项工作组合起来。

再如 ifttt 这样的网站,你都可以实现编程的分支功能了——如果明天天晴的话,就发给你一条短信,去爬山。完成这样的功能,你根本不需要是程序员,你只要会操作电脑,会上网就可以了。

互联网的资源,将被得到更好地组织和获取,以 YQL(Yahoo! Query Language)为例,你可以体会到这一点:

1
2
3
select * from html
where url='http://www.dangdang.com/'
and xpath='//ul[@id="homepage_promotion_count_ul"]/li/p[@class="name"]/a'

它做了这样一件事:从当当网的页面去获取数据,而数据的路径通过 XPath 表达式给出。如此一来,你可以感受到,整个互联网就变成了一个超级大型的数据库。当然,这样的语法还是不够简单,希望能看到类似 ifttt 的应用出现,目的却是让不会编程的人也可以轻松从互联网这个大型数据库中查询自己需要的东西。

另外,未来需要普通人掌握的编程技能也不尽相同,就如同现在年轻人和老人的阅读技能大不相同一样。但是可以确定的是,生活中会充满编程的行为,让机器替代自己做更多的事。

所见即所得

好吧,在这里我谈这个话题也和我的启蒙编程语言是 VB 有关。你也许和我一样,谈到所见即所得的时候,想到很多编程语言、IDE,甚至包括 FCKeditor 这样的富文本编辑组件。Google 已经做了这样的尝试,App Inventor 就是这样的东西,它是为手机端准备的编程软件,你可以看看这样的宣传视频:

上面这则视频似乎只是针对非专业程序员的傻瓜式工具,那么再来看看这个在网上已经广为流传的 Bret Victor 的神一般的演讲,题为《Inventing on Principle》,第一次看的时候,你一定会像我一样惊讶地合不拢嘴:

所见即所得使得编程的过程更贴近人最自然的思维,而一张丰富画面所传递的内容远远大过枯燥的代码行语义和数值。

编程范型的进化

相较于硬件的摩尔定律,软件的发展似乎真的是 “太慢了”,相较于硬件淘汰的速率,几十年历史的编程语言却可以长盛不衰地存活下去。好在软件的发展也是有驱动力的,软件的复杂性就是直接驱动力之一。想想现在做一个普通网站的代价,和十五年前比较,我们能省做多少功。

很多时候程序员会觉得,算法还是不容易转变成代码,即便是简单的算法,思路简单的纸上实现,变成代码却比较冗长。我觉得大部分情况下这不是你编码技巧的问题,而是编程语言的问题——换句话说,如果你使用一种合适范型的编程语言,兴许就可以轻松解决这个问题——即便这样的语言并不一定好找,并不一定容易设计。

我们都知道从过程式编程到面向对象编程的进化,可是如今常用的编程范型已经远远超出这两者了,例如声明式编程、面向方面编程、基于规则的编程等等,我们的固有思维模式一次有一次遭到挑战。

以 Prolog 语言为例,它是由事实和规则组成的,我们先告知程序这些已知的事实和规则,再去询问程序一个需要推断的问题,让它给出推断的结果。比如:

1
2
3
4
love(you, dog).
love(he, dog).
love(she, cat).
friend(PA, PB) :- \+(PA=PB), love(PA,Animal), love(PB,Animal).

我来解释一下:

  1. 给定了三个事实:你爱狗,他爱狗,她爱猫;
  2. 给定一条规则:对于人物 A(PA)和人物 B(PB),如果人物 A 和人物 B 不是同一个人(“\+” 表示取反),人物 A 爱动物 Animal,并且人物 B 也爱同一种动物 Animal,那么人物 A 和人物 B 就是朋友(friend)。

好,现在来询问程序一个问题:

1
| ?- friend(you, he).

你和他是朋友吗?程序判断你爱狗,他也爱狗,就给出结论:

1
yes

这只是基于规则的编程范型的一个例子,不同范型的语言适用于解决特定的问题。我们在未来能看到更多范型的语言,目的就是让对特定问题的表述和解决更见简单和易于理解。

创造性的工作在哪

既然编程会成为一件几乎人人都能够做的事情,那么程序员,你的价值在哪?

好,先来看看为什么越来越多的人可以编程呢?因为编程的门槛更低了。即便是现在,编程的门槛已经比二十年前低得多了:不明白网络协议?好,已经有现成的类库可以使用;不懂平台差异?好,你只需要在无差别的虚拟机上写程序;不理解内存管理?好,让程序来自动帮你完成这件事情……

所以,如果你还在为了解语言的不良设计、历史原因等等遗留下来的陷阱,或者为知道某个提高语言表达的语法糖而沾沾自喜的时候,你想过没有,这样的优势很可能太不值钱了。

程序员最有价值的部分不应在 “翻译” 上,即不应在将思考的结果翻译到代码这一层面上。编程的未来一定是让编程工作越发贴近人本质的思考,这样的 “翻译” 工作导致的歧义、错误、陷阱会越来越少,把清晰的思考变成代码是一件越来越简单的工作,以至于某天可以让能够读懂人脑的计算机来完成。

另一方面,很多公司的老大们却都不懂程序员,在他们心目中,“程序员” 只是高成本的劳动力,只会在一台搞不懂的机器上干一些更搞不懂的事情。

看到这里,你是不是也发现,程序员本质上应该和音乐家、画家类似,往往也让许多人无法理解,而且艺术的价值,常常也都来源于思考?

音乐家有了更先进的乐器,画家有了更丰富的画笔,情感的抒发都可以更加自由。甚至有一天,拿掉乐器和画笔这些传统物理实体,给大脑接上两根线,思考之后的乐谱和画册就诞生在电脑里了。

可是,即便计算机可以帮助人思考,它却不能全面代替人思考,尤其对于艺术的创作。即便到了 100 年以后,程序员创造性的工作,还是无从替代的。

最后,放开枷锁去想象吧,100 年以后,编程会是什么样子,程序员又会是什么样子,我期待你的答案。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. C++程序员和 Java 程序员的差异
  2. 程序员看法上的几个典型错误
  3. 解雇专业的运维人员吧
  4. “ 你不适合做程序员”
  5. 致那些自嘲码农的苦逼程序员

2 thoughts on “编程的未来”

  1. 天方夜 says:
    03/10/2014 at 9:54 PM

    我体会到的编程的意义是让生活变得更方便和更快乐,我认为 100 年后依然需要用编程提高生活质量,具体方式也许变成画图编程。

    Reply
  2. 胖徐 says:
    10/24/2012 at 1:40 PM

    没有未来, 在天国!

    Reply

Leave a Reply to 天方夜 Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme
Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接