对人工智能的名言

对人工智能的名言

1.人工智能语言的名家名言

谈到LISP和PROLOG两种AI语言的重要性，我们可以从美国AI界的权威学者、麻省理工学院教授P.H.Winston（温斯顿）所说的三段话来体会：

(1)温斯顿认为，LISP 语言是AI的数学，不仅对AI的机器实现有重要意义，而且是AI理论研究的重要工具。

(2)“在中世纪，拉丁文和希腊文的知识对所有学者来说，都是必不可少的。只懂一种语言的学者必然是一个残缺不全的学者，他缺乏从两个方面来观察世界所获得的那种理解力。同样地，现代的AI专业人员如果不能同时大致通晓LISP和Prolog，也犹如一个残疾人，因为就广义来说，这两种人工智能的主要语言的知识都是必不可少的。”

“我一直热衷于Lisp,Lisp是在MIT被制造并且在那儿成长起来的。”

(3)概括地说，计算机语言的发展正是一个从HOW型低级语言向WHAT型高级语言进化的过程.在HOW型语言中，程序编制者必须详细说明运算是怎样（HOW）一步一步进行的；而在WHAT型语言中，程序编制者只需简单说明要做的事情是什么（WHAT） 。 …现代的LISP语言是这些语言的佼佼者，因为采用Common Lisp格式的Lisp具有非凡的表现力，但是如何做某件事情仍然是有待于Lisp程序编制者来表达的东西.相反，Prolog是一种明显地冲破了HOW型语言陈规的语言， 它鼓励程序编制者去描述情况和问题，而不是那些用来解决问题的详细步骤。”

由以上论述可以看出LISP语言和Prolog语言对人工智能学科和人工智能学者的重要性。

一般来说，LISP可以称为人工智能的汇编语言， Prolog是人工智能更高级的语言。

2.急需《人工智能》的经典台词

精彩对白

David: Is it a game？ 大卫：这是一个游戏吗？ Monica: Yes. 莫尼卡：是的。 Monica: You won't understand the reasons but I have to leave you here. 莫尼文卡：你不会明白的，但是我不得不把你留在这儿。 David: Is it a game？ 大卫：这是一个游戏吗？ Monica: No. 莫尼卡：不。 David: When will you come back for me？ 大卫：你什么时候会回来？ Monica: I'm not, David. You'll have to be here by yourself. 莫尼卡：我不会回来，大卫。你将独自留在这儿。 David: Alone?

百科里太少，就只有这些。

3.电影《AI人工智能》经典台词

电影《AI人工智能》经典台词：

David: Is it a game?

大卫：这是一个游戏吗？

Monica: Yes.

莫尼卡：是的。

Monica: You won't understand the reasons but I have to leave you here.

莫尼文卡：你不会明白的，但是我不得不把你留在这儿。

David: Is it a game?

大卫：这是一个游戏吗？

Monica: No.

莫尼卡：不。

David: When will you come back for me?

大卫：你什么时候会回来？

Monica: I'm not, David. You'll have to be here by yourself.

莫尼卡：我不会回来，大卫。你将独自留在这儿。

David: Alone?

开始的时候，那个无所不知的博士回答的都是不沾边的，后来乔选了“常识”和“童话故事”两个新项目是，大卫重新提问，画面狂闪，然后屏幕就出来一段话，下面的：

came away,o human child,to the waters and the wild,with the fairy hand in hand,for the word's more full of weeping than you can understand.you quest will be perilous,yet the reward is beyond price.

真正的小男孩，越过高山和大海，和仙女手牵手，世人皆悲哀，你不会明白，为爱走天涯，报答终无价！

我个人觉得最经典的一句是在最后，莫妮卡被复活后，刚睁开眼，大卫缓缓的流下眼泪，说："I found you。”,"Hi!","Hi!"。

还有在最后莫妮卡给大卫过生日是，让大卫吹蜡烛，并许愿的时候说的："now,make a wish.""it came true already."

4.为什么最近有很多名人,让人们警惕人工智能

科技发展迅速，名人担心的不是人工智能，而是日后可能出现的人工生命，这就意味着人工智能拥有一定的思维的时候，如拥有生命一样会自我思考的时候，很可能对人类有所不满，而做出反人类的举动，要知道那时就是你用自己的脑子和计算机比智慧的地步了，这是极度危险的。

“人工智能”一词最初是在1956 年Dartmouth学会上提出的。从那以后，研究者们发展了众多理论和原理，人工智能的概念也随之扩展。人工智能（Artificial Intelligence），英文缩写为AI。它是研究、开发用于模拟、延伸和扩展人的智能的理论、方法、技术及应用系统的一门新的技术科学。人工智能是计算机科学的一个分支，它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器，该领域的研究包括机器人、语言识别、图像识别、自然语言处理和专家系统等。人工智能从诞生以来，理论和技术日益成熟，应用领域也不断扩大，可以设想，未来人工智能带来的科技产品，将会是人类智慧的“容器”。

人工智能是对人的意识、思维的信息过程的模拟。人工智能不是人的智能，但能像人那样思考、也可能超过人的智能。

5.求有关人工智能的作文素材

太多了，最典型的是“新阿尔法狗”踏平人类围棋界，这个素材。

自2016 年12 月29 日以来，在国内在线围棋平台弈城和野狐上，一个注册账号为“Master（大师）”的棋手轮番挑战众多顶尖围棋手。在与韩国的朴廷桓、日本的井山裕太、中国的柯洁和“棋圣”聂卫平等人的61 场对弈中，Master 取得了60 胜1 平的战绩。唯一一场平局是Master 与中国职业围棋手陈耀烨之间的对弈，这一局还是因为陈耀烨掉线，才终止了Master 的连胜局面。

还有机器人开启了宇宙征程，这个素材也很新。

宇宙里有一颗星球，上面有“海洋世界”，有丰富的有机物和流动的液体，其有机质正在经历生命出现前的化学变化，它就是土星的最大卫星泰坦星（Titan，即土卫六）。但无论是探索泰坦星的生命演化历程还是侦测泰坦星是否适合人类居住，人类宇航员都无法做到。所幸，在人工智能时代，人类无法完成的宇宙探索任务，可以由智能机器人来代劳。

目前，美国科学家正准备挑选一种“蜻蜓”双四轴智能机器人飞行器前往泰坦星进行探测。这款机器人飞行器可以像蜻蜓一样灵活地飞翔，能够提前探知来自周围的威胁，从而躲避各种危险袭击。它不需要氧气，不需要饮食，能抗拒极大的大气压力，有足够的能量，身上携带有各类科学仪器，可以随时停靠在泰坦星上的任何地点进行科学考察。科学家在它的“大脑芯片”中植入了科学分析和判断程序，可以定期将对泰坦星的探测结果和图像发送给地球。

最近看了一本素材书，里面全是新颖有趣的素材，你可以上网搜搜这本《主题素材串串烧》。

这5个编程名言还请您收好

三月份的开篇翻译，把我自己给搞的不知所措，一看名字的时候，感觉对编程这方面挺有帮助的，5个著名的编程名言，以及解释，吸引了我的兴趣。

紧接着，看了第一段，作者筛选的引用至少有20年的历史，那肯定是经久不衰，经典的Tips，很赞。看了几个小标题，以及粗略的看了下重点关注的描述，我更加感兴趣了。

但是，当我全身心投入到翻译行动的时候，我把我自己坑了。整个翻译，有点长，还有长句。不过不过，这不是问题，当你看完这篇，相信你肯定会引起共鸣，至于是什么共鸣呢？肯定是基于你编码能力的共鸣，带着这份好奇，请你好好看下去吧。

我的翻译能力有限，有时候还是借助于翻译软件来，所以翻译不到之处，还请大家谅解，可以去看原文，和我多多交流。每周一篇翻译，我坚持着我的坚持。

原文地址：`https://medium.com/young-coder/5-famous-programming-quotes-explained-4da607906c1`

作者：Matthew MacDonald

5个著名的编程名言，解释

> 通过理解这些永恒的见解，你将成为更好的开发人员。

成为一名优秀的程序员，就是让你自己接受不断学习的生活（活到老，学到老）。包括新功能、新语言、新工具、新框架等优秀的源头--学习永不停息。但是，其实计算机科学也是一个令人惊讶的传统领域，这是基于久经考验的原则得出来的。我们已经添加了面向对象、现代硬件以及人工智能。然而，尽管发生了这么多的变化，许多上一代人提出来的见解在今天仍然适用（这点和我们现在的名言警句类似）。

在这篇文章中，我剖析了一些我最喜欢的关于计算机科学的引用。我设置的唯一条件就是，每个优秀的引用必须至少有20年的历史。因为古老的技术很快就会变得毫无用处，而我们编承祖先的古老戒律却有更强的持久力。

1. 关于Indirection

> "计算机科学中的所有问题都可以通过另一种间接的方式来解决"。-- David Wheeler

这里有一个很少被开发者愿意解释却又经常被复用的compsci的引用。但这是我最喜欢的编程真理之一，因为它触及了编码的核心。

开始考虑Indirection的最简单的方法是想像层次。例如，假设您有一个小项目，需要将组件A放入组件B：

两个都是标准的组件，因此你不能破坏他们并更改他们的工作方式。你可以构建一个全新的组件，但这需要大量的工作和不必要的重复。一个更好的方式就是这两个部分之间添加一层--一个适合于两个组件并在它们之间进行转化的适配器。（其实就是设计模式中的适配器模式）

现在，如果Indirection仅仅是添加一个新层来讲不兼容的部分组合在一起，这将是很好的，也确实很有用。但是围绕问题进行构建来解决问题的想法是一个从底层一直延伸到顶层的概念。当你试图将新的数据模型适配到旧的用户接口时，你就会看到它；当你试图将遗留应用安装到一个新的web后端服务器时，你就会看到它；当你需要绑定更好级别的特性（如日志和缓存）或协调更高级别的服务（如消息传递和事务）时，你就会看到它；在金字塔的顶端，你将会接触到像机器学习（当你不能为你需要的行为编码时，再写一层代码来帮你找出它）这样的少数主题。

很多人会告诉你，编程就是用一种即使电脑小白也能理解的语言写出明确的指令。但是大卫·惠勒的名言揭示了

更好的见解：好的编程是要爬上抽象的阶梯才能到达最通用的解决方案。

相关引用：

间接是强大的，但是复杂性是有代价的。人们很少引用惠勒关于间接的后续评论：

> 但通常会产生另一个问题 -- David Wheeler

从那时起，这一真理就一直让程序员在商业上如日中天。

2. 关于简单

> “简单是可靠性的先决条件”。-- Edsger Dijkstra

不少明智的程序员警告我们不要使代码过于复杂。但很少有人能比荷兰计算机科学先驱 Edsger Dijkstra 更清楚地说明复杂性的成本。

这里的见解是：你不会选择简单作为送给未来的礼物。你不做因为您正在期待机会重用您的代码，或者因为您希望在代码评审时让它看起来更整洁，或者是因为您想使其更易于修改（尽管所有这些好处都是宝贵的！）。您这样做因为简单是一个先决条件。如果没有简单性，就永远不可能有可以信赖的可靠代码来开展业务或处理您的数据。

要接受Dijkstra的观点，我们需要重新定义“好代码”的含义。不是最短的代码。它不一定是最快的代码。绝对不是最聪明的代码。可以信任的代码。

相关引用：

保持代码简单的最佳方法之一就是记住少即是多。Dijkstra 提供了一个可帮助我们牢记这一点的指标：

> “如果我们希望计算代码行，则不应将它们视为‘产生的行’，而是看作‘花费的行’”。-- Edsger Dijkstra

3. 关于可读性和重写

> “读代码比写代码难”。 -- Joel Spolsky

乍一看，这个引用来自软件传奇和StackOverflow共同创建者Joel Spolsky似乎是正确的，但看似肤浅。是的，代码可能很密集，简短而又冗长。这不仅仅是别人的代码。如果您看一年前的工作，您可能需要一些时间来整理一下您曾经非常了解的逻辑。

但是Spolsky 的洞察力却有所不同。您无法阅读的代码的危险不仅仅是显而易见（很难对其进行更改和改进）。相反，更大的危险是复杂的代码似乎比实际情况更糟。其实，尝试了解别人已经写好的代码是如此之好，以至于您可能会被吸引犯 Spolsky所说的最严重的错误-决定从头开重写该代码始。

并不是说重写不能改善系统的体系结构。他们绝对可以。但这些改进付出了巨大的代价。他们重置测试和调试错误的时间固定，两项活动比单纯的编码要花更长的时间。重写很诱人因为它们是软件开发中最常见的偏见之一：我们低估了做概念上简单的事情的努力。这就是为什么最终的5％项目需要50％的时间。简单的事情可能会非常耗时！和解决您已经解决的问题相比似乎没有比这容易的了。

因此，如果您不应该重写所有内容以使其完美，那么有什么更好的解决方案？答案是让每个开发人员都参与恒定大小的重构。这个为您提供小的，连续的代码改进-真正有回报，并且风险很小。您可以在编码的过程中提高可读性。

相关引用：

如果您仍然不确定可读性的重要性，Martin Fowler可以帮助您解决这一问题角度来看：

> “任何人都可以编写计算机可以理解的代码。优秀的程序员写的代码人类都可以理解。” -- Martin Fowler

换句话说，程序员的工作不仅是写代码，更在于做有意义的事情。

4. 关于重复

> “不要重复自己。每一项知识必须有一个单一的，明确的，权威的系统中的表示形式。” — Andy Hunt and Dave Thomas

每个自重的程序员都知道重复是万恶之源。如果您在不同的地方写相同的东西，你在做额外的工作，测试和调试。更糟糕的是，您正在引入不一致-例如，如果代码的一部分已更新，而其他类似的代码没有同步更新。程序不一致使您的程序存在偏差，而您存在偏差的程序不再是可行的解决方案。

但是，重复代码并不是造成严重破坏的唯一地方。这个版本的著名的“请勿重复自己”（DRY）规则将无重复原则扩展为覆盖其他可能隐藏矛盾之处。我们不再谈论代码重复。我们也在谈论系统中的重复-系统具有代码知识的许多不同方式。它们包括：

- 代码声明

- 代码注释

- 开发人员或客户文档

- 数据模式（例如，数据库表）

- 其他规范，例如测试计划，工作流程文档和构建规则

所有这些层都可以彼此重叠。而当他们这样做时，他们就有可能引入同一现实的不同版本。例如，如果文档描述一种工作方式，但应用程序遵循另一种方式？谁拥有真相？如果数据库表与代码中的数据模型不匹配怎么办？或者注释描述了算法的操作，与实际的实施方式不符？每个系统都需要一个单一的、权威的，其他一切都必须高度统一。

顺便说一下，竞争版本的真相不仅是小规模项目中的问题或设计不良的代码。最好的例子之一是随着XHTML和HTML5之间的斗争。一个阵营认为规范是官方事实，需要对浏览器进行更正以遵循它。另一派声称浏览器行为是事实上的标准，因为这就是当设计师们写网页时已经想到了。最后，浏览器版本的真相获胜。从这一点上来说，HTML5的浏览器就是这么做的 -包括快捷键，他们允许和他们接受的错误.

相关引用：

代码和注释彼此矛盾的可能性引发了关于注释是否弊大于利的激烈辩论。极限编程的支持者公开怀疑：

> “代码永远不会说谎；代码注释有时会。” - Ron Jeffries

5. 关于难题

> “计算机只有两件事科学：缓存失效以及命名事物。” -- Phil Karlton

乍一看，这句话似乎很有趣，但却是普通的编程笑话。听起来很困难的内容（缓存无效）与听起来很轻松（为事物命名）的事物可以立即关联。每一个程序员投入了数小时的工作来解决一个荒谬的琐碎问题，例如参数传递顺序错误或大小写不一致的变量（感谢JavaScript）。只要人类需要与机器合作完成任务，编程将成为高级系统规划和琐碎输入错误的混搭。

但是，如果您再看一看Phil Karlton的引用，还有更多需要解决的问题。命名事情并不难，因为程序员的生活经常因小小的头痛而毁了。这也是因为命名问题实际上是每个程序员最关心的重要工作：软件设计。换句话说，您如何编写清晰的代码，干净，一致吗？

有很多方法可以使命名错误。我们都看到过以变量命名的数据类型（myString，obj），缩写（用于产品目录的pc），一些琐碎的实现细节（swappable_name，formUserInput），甚至什么都没有（ret_value，tempArray）。容易陷入基于以下方式命名变量的陷阱您当时正在使用它做什么，而不是其中包含什么。布尔值是特别棘手的-当 progress 标记进度开始，表明您需要在用户界面中显示进度信息，或完全标记某些内容不同？

但是变量名仅仅是开始。命名类提出了如何将代码分成独立部分的问题。命名 public 成员将影响您的工作方式显示允许应用程序的一部分与另一部分交互的界面。锁定这些名称不仅描述了一段代码可以做什么，而且确定它将做什么。

相关引用：

> “计算机科学有两件事：缓存失效，事物命名和一对一错误。” -- Leon Bambrick

喜欢这个清单并想提高自己的技能？ 查看《5本书可以帮助您成为更好的程序员》这篇我下周在进行翻译。

结语

很高兴，你和我一样坚持看到了最后，是不是对自己编程过程中有很多想改变的地方呢？比如简单行，可读性，DRY原则，是不是让你铭记在心，还有最后说的缓存失效很难，命名很简单的错觉。

我感受很深的就是DRY原则，以及命名很简单这两点。因为我维护的程序里，真的有重复操作的代码，改一个地方，忘记改另一个地方，结果经常被测试怼；让我有想重构的冲动，前几天刚把这个老大难给搞定。还有命名，总不能几个月只会自己看这个命名，却不知道什么意思吧。

最后作者留了一个菜单，5本书帮你成为更好的程序员，下周的素材找好了，约吗？

> 作者：程序员小跃

> slogan：当你的才华还无法撑起你的野心时，那应该静下心来好好学习