动态语言在现实生活中的好处？

Question

我正在探索开发新系统（网络应用程序）的几种可能性。

我是一个“老式”的人，本质上是面向对象的（多年前从程序转换而来）。 我尝试了 Python 并研究了一点 Ruby，但坦率地说，我又被 Microsoft 的工具（C#、ASP.NET MVC）所吸引。 所有这些运行时输入、基本内容上没有编译器错误等等只会让我在构建大型复杂应用程序时变得更加困难。

我经常听到人们谈论使用动态语言可以做的伟大事情，但除了狗、猫的例子以及如何快速地编写一种很酷的方法来计算事物之外，Visual Studio 的“工业实力”似乎消除了这些动态语言提供了一些巧妙的小东西，特别是现在您拥有 VS 的免费快速版本和免费供初创企业使用的完整版本。

我觉得我在这里遗漏了一些东西，因为大型应用程序确实是用动态语言开发的，那么在查看大型复杂应用程序时，这些语言使您能够做哪些伟大的事情呢？ 是什么让你放弃VS的实力？

Answer 1

考虑这样的情况：您有一个带有单个参数的子例程：

sub calculate( Int $x ){ ... }

现在您的需求发生了变化，并且您必须处理多个参数：

multi sub calculate( Int $x ){ ... }
multi sub calculate( Int @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

请注意，不同版本之间几乎没有变化。

现在，如果您发现确实应该使用浮点数，该怎么办：

multi sub calculate( Num $x ){ ... }
multi sub calculate( Num @x ){
  my @ret;
  for @x -> $x {
    push @ret, calculate( $x );
  }
  return @ret;
}

这是一个比以前更小的更改，并且请注意，调用这些子例程的任何代码段都将继续工作，而无需进行任何更改。

这些示例是用 Perl6 编写的

Answer 2

我知道已经有一段时间了，但接受的答案列出了不限于动态类型语言的属性。 例如，#4（更少的代码）对于 Scala 也是如此（如果我没记错的话）。 这对于 Groovy 来说绝对是正确的（它构建在 Java 之上，因此从技术上讲，groovy 既是静态的，也是动态的）。 我唯一同意的是

来自维基百科的#7（韧性），

动态编程语言是一种高级编程语言，它在运行时执行静态编程语言在编译期间执行的许多常见编程行为。 这些行为可能包括通过添加新代码、扩展对象和定义或修改类型系统来扩展程序。 动态程序员还可能包括动态类型。

根据我的经验，动态语言的优点是更少的代码/更高效的代码和更好的“最佳”实践（例如强大的测试文化）......这些并不是动态语言特有的。

说到测试文化，某些动态语言爱好者（特别是 Ruby）声称他们编写的所有测试（测试感染）也使他们能够轻松重构应用程序。 我倾向于不相信这种说法——编写得不好的测试（非常非常容易编写）往往会成为维护的噩梦。

总结一下：动态语言往往有助于快速交付产品，应用程序可能易于维护，也可能不易维护，但对于高性能应用程序来说却很糟糕（静态编译的应用程序要快得多）

Answer 3

“你能多快编码”让我非常担心，所以我很高兴地放弃了漫长而缓慢的编译过程。

动态语言的优点。

1. 没有编译，没有构建。 只需编码和测试，然后部署到生产环境。

2. 立即满足。 无需花时间思考 API 调用可能是什么。 只需在 Python >> 中交互式输入即可。 提示并查看它实际做了什么。

3. 设计周期非常非常短。 我可以只对类进行编码，对它们进行单元测试，然后就可以完成，而不是用额外的接口定义和适当的抽象声明和覆盖来精心制作一个类层次结构。

4. 更少的代码。 动态语言内省减少了源代码的体积。 我不会在我的应用程序中写这些东西； 我依靠框架来为我做到这一点。 但基于框架的代码往往很短； 没有 Java 中常见的重复声明，您必须在 XML 配置中重复某些内容。

5. 没有什么神秘的。 正如我们在 Python 社区中所说：“使用源代码，Luke。” 框架的作用或 API 的真正含义没有任何歧义。

6. 绝对的灵活性。 当我们的需求发生变化时，我们不必与破坏整个架构的毁灭性变化作斗争。 我们可以简单地对一些类进行更改，因为 Python 的 Duck Typing 消除了在我们认为不需要的地方修改缺失的接口定义的需要。 他们只是不存在； 我们没有编写的代码是我们不需要修复或维护的代码。

7. 韧性。 当我们的精算师脑子有问题时，我们不必花几个月的时间来弄清楚如何将这种新的、更复杂的承保模型集成到应用程序中。 几乎任何东西都可以被挤进去。同样，这完全是鸭子类型的结果。 我们不再需要将其强制安装到无法预测新业务模型的架构中。

8. 由于源是应用程序，因此源可以是它自己的配置文件。 我们没有某些外国语法的 XML 或 INI 配置文件。 我们有 Python 的配置文件。 Django 框架做到了这一点，我们遵循他们的领导。 我们有非常复杂的模型数据声明用于销售演示和单元测试。 超级复杂的数据实际上是来自数据库的 Python 对象的集合——除了——我们省略了加载数据库。 只需调整 Python 对象构造函数而不是加载 SQL 数据库会更简单。

[顺便提一句。 在使用 Cobol、Fortran、PL/I、Java、C、C++ 开发软件 30 多年之后，我只是厌倦了大多数编译语言所需的相对较低级别的手动优化。 几年前，我读过一篇关于大多数编译器效率低下的评论：它引导我们创建复杂的构建系统来解决编译器的限制。 我们只需要 make 因为 cc 太慢了。]

---

编辑

动态编程并不能让你成为天才。 它只是节省了很多时间。 您仍然需要管理学习过程。 在所有语言中，你不知道的事情都是困难的。 动态语言可以让您逐步进行，一次发现一件新事物，而无需做大量设计​​工作才发现您的假设是错误的，从而为您提供杠杆作用。

如果您想根据被误解的 API 编写大量代码，那么动态语言可以提供帮助。 你可以自由地用一种语言编写大量崩溃和烧毁的代码：C#、VB、C++、Java 或 Python。 你总是可以编写出不起作用的代码。

编译器会提前警告您该代码将无法运行。 通常，不编译是一个很大的提示。 但是，您仍然可以编写大量可以编译但无法通过所有单元测试的代码。 编译器只检查语法，不检查语义。

Python 可以提前警告您代码将无法运行。 通常，您无法让它以交互方式运行。 但是，您仍然可以编写大量无法通过所有单元测试的代码。

Answer 4

我的经验

我曾与这两家公司共事过，总共大概有十年的专业经验。

有趣的是，我花费了更多的时间尝试让静态类型语言理解我想要做的事情（可能是几周 - 可能总共是几个月），而不是修复动态类型错误引起的错误（可能是每年一两个小时？）。

研究

人们已经非常努力地寻找证据表明其中一种在程序员生产力方面更好，但我读到的最新评论表明没有强有力的证据证明这两种方法。

极权主义

静态类型分析在某些情况下很有用。 我认为它不应该被固有地融入到你的语言中。 它应该是你的交互式计算环境中的一个工具，与你的测试、你的 REPL、你的重构、你的文档、你的文字编码等一起。

静态类型系统可以让你思考有用的事情。 在像 Haskell 这样带有类型类和 Monad 的语言中尤其如此（我承认我仍然没有真正理解）。 这是一件好事，但我觉得相信它总是是一件好事是极权主义的。 你应该在适当的时候考虑一​​下。 一种语言不应该让你从开发之初就思考它或意识到它。

限制太多和限制太多 限制不够 非

图灵完备的静态类型系统的表达能力有限。 为什么要使用一种新的特殊领域特定语言将其融入到语言中，只是为了讨论类型？ 现在，您的语言决定了您可以访问的表达能力的确切水平。 想要更多？ 您需要重新编写代码或更新语言。 想要更少吗？ 你运气不好——使用不同的语言。

相反，为什么不在需要时使用基本动态语言来描述类型和类型系统呢？ 作为一个图书馆。 它更具表现力； 更强大（如果愿意的话）； 更灵活； 并意味着更小的基础语言。

样板文件

静态类型语言似乎鼓励样板文件或代码生成。 我不确定这是否是固有的。 也许一个足够强大的宏观系统可以克服它。 我正在将 Swift 中测试的模拟状态与 Objective C 中的测试状态进行比较。

整体静态

类型语言似乎鼓励整体应用程序——这是我无法支持的观点和观察，但它似乎成立……它们或它们附带的工具似乎鼓励整体应用程序和思维。

相反，在交互式计算环境中，您不需要构建新的应用程序，而是扩展系统以使其执行更多操作。 我所知道的系统（Lisp 机器、Smalltalk 和 Unix——其工具之间有一个动态类型接口）使用动态类型将各个部件组装在一起。

我们应该为整体构建微小的扩展，而不是着手构建新的整体应用程序，因此这种单一趋势（如果存在）是具有破坏性的。

速度

最快的动态跟踪 JIT 编译器可以生成快速的代码，而且它们仍然是一项相当年轻的技术。 不过，您也可以使用静态类型语言来做到这一点。

长期

我怀疑从长远来看，我们最终会得到支持强大静态分析的环境，您将能够在其中声明类型和协议，并且系统将帮助您查看它们是否满意，或者帮助向您展示隐含类型。 但您不需要这样做。

Answer 5

静态类型是过早优化的一种形式。 它迫使您预先做出详细决定，而您可能不具备做出这些决定的知识。 除非您创建足够的类型以具有逻辑意义，否则它并不会特别有助于程序的正确性。 这使得动态更改数据结构变得困难。

你从中得到的是非常有限的正确性检查：非常有限，因为它没有区分使用整数的方法。 假设我们正在处理行和列； 两者都可能是整数，但行和列变量不应该互换使用。 您还可以获得优化，这可能是一件非常有用的事情，但不值得放慢初始开发速度。 您可以通过编写适当的测试来弥补正确性检查。

Common Lisp 类型系统对此很有帮助。 所有数据对象都知道它们的类型，如果您愿意，您可以显式指定该类型。

eval 循环类型的执行模型使得在编写例程时测试例程变得非常容易。 您不必预先显式地编写测试（尽管没有什么可以阻止您这样做）； 您可以编写它们并即时执行它们（然后您可以将其细化为测试套件 - 将其视为增量测试开发）。

没有很长的构建步骤可以更轻松地进行测试驱动开发，因为运行测试的速度要快得多。 您不必每次想要测试时都中断正在做的事情。

当我听到人们抱怨动态语言时，我想起了人们抱怨没有独占锁的版本控制系统。 有些人需要很长时间才能意识到迁移到现代 VCS 所获得的好处，同样有些人也需要很长时间才能欣赏动态语言。

Answer 6

一般来说，我更喜欢谈论“交互式”语言而不是“动态”语言。 当您只有一个编辑/编译/运行周期时，任何周转都需要很长时间。 嗯，至少按照“需要保存、编译、检查编译报告、测试运行、检查测试结果”的顺序。

使用交互式语言，通常很容易修改一小部分，然后立即测试结果。 如果您的测试运行仍然需要很长的时间，那么您还没有赢得那么多，但您通常可以在较小的情况下进行测试。 这有利于快速发展。 一旦您有了已知正确的实现，这也有助于优化，因为您可以快速开发和测试新的改进函数并尝试不同的表示或算法。

Answer 7

这是我的回答的一部分 之前的类似问题（我知道 C# . 使用 Python 会提高工作效率吗？）：

我自己就有 C#/.NET 背景。 开始在 abt 中进行 .NET 编程。 2001 年，大约在同一时间 Python 被引入。 2001 年，我花在 C# 和 Python 上的时间大约是 90% C# / 10% Python。 现在，这个比例是 5% C# / 95% Python。 在我的公司，我们仍然维护着基于.NET 的产品线。 但所有新东西都是基于 Python 的。

我们已经用 Python 创建了不平凡的应用程序。

根据我的经验，与 C# 相比，Python 的工作效率更高的是：

• 它是一种动态语言。 使用动态语言通常可以让您从应用程序中删除整个架构层。 Python 的动态特性允许您以比 C# 更自然、更灵活（语法方面）的方式创建可重用的高级抽象。
• 图书馆。 社区提供的标准库和大量开源库都是高质量的。 Python 的应用范围广泛意味着库的范围广泛。
• 更快的开发周期。 没有编译步骤意味着我可以更快地测试更改。 例如，在开发 Web 应用程序时，开发服务器会检测更改并在保存文件时重新加载应用程序。 只需按一下键即可从编辑器中运行单元测试，并立即执行。
• “轻松访问”常用功能：列表、列表推导式、生成器、元组等。
• 语法更简洁。 与典型的 .NET web.config 文件相比，您可以用更少的代码行创建基于 WSGI 的 Python Web 框架 :-)
• 很好的文档。 好书。

Answer 8

交互式外壳！
这是生产力的巨大提升。 只需启动 irb/python 即可进入交互式 shell
（分别适用于 ruby​​ 和 python）。 然后，您可以交互地测试您的类、函数、试验表达式（非常适合正则表达式）、不同的语法和算法。 这是真正的程序员游乐场，也是调试的好工具。

关于错误，我只有两分钱：

所有这些运行时输入，没有编译器
基本内容等方面的错误只会导致
我的生活变得更加艰难
构建大型复杂应用程序。

编译器可检测错误是您在执行各种自动测试（单元、功能等）时将检测到的错误，以及您无论如何都应该编写的错误。
也许 Linus Torvalds 会说：回归测试”？那是什么？如果能编译，那就很好，如果能启动那就完美，但他有数千名测试人员可以完成这项工作
他。 啊，使用交互式 shell，您将获得有关语法的自动反馈，就像编译应用程序时一样，但代码会就地执行。

Answer 9

我也喜欢静态类型。 但我发现，当我编写 Python 时，我并没有那么想念它（只要我使用的类有很好的文档记录——而且我认为没有任何语言功能可以让我们避免糟糕的文档） 。 在编写 C++ 时，我也不会怀念 Python 的大部分动态功能（我怀念 lambda：即使语法很糟糕，也要使用 C++0x。还有列表推导式）。

对于错误检测，大多数“传递了错误的类型”和“调用了错误的方法”错误并不微妙，因此主要区别在于异常替换了编译器错误。 您必须确保实际执行每个代码路径和所有重要数据路径，但当然，无论如何您都会为严肃的项目执行此操作。 我怀疑测试可以分配给给定变量的所有类很少会很困难。 主要问题是，习惯 C++ 的人已经学会了依赖编译器，而不是努力避免编译器会捕获的大类错误。 在 Python 中，您可以选择在编码时考虑它，或者等到测试运行后再找出它。 同样，如果要找到所有调用站点，则需要在 Python 中对“更改参数并查看哪些内容无法编译”的 C++“自动重构”操作进行一些修改。

因此，您必须确保运行正确的测试子集，因为大型 Python 应用程序的完整单元测试运行将花费比当前 C++ 代码/编译/代码/的“编译”阶段可接受的时间更长的时间编译/编码/编译/测试循环。 但这与不想用 C++ 重建所有内容是完全相同的问题。

当您的代码实际上很难运行时（例如使用嵌入式设备，或者您无法在本地重现的特别奇怪的服务器环境），静态类型会获胜，因为您在弄乱串行电缆之前会捕获更多错误，并且同步。 但这就是为什么无论您使用什么语言编写，都需要一个模拟器，以及为什么对于严肃的服务器代码，如果开发人员的机器无法模拟生产，您需要一个适当的测试环境。

另外，值得记住的是，许多 C++ 编译器错误和警告实际上与您的设计无关，它们与这样一个事实有关：有很多不同的方法可以编写看起来正确但行为完全错误的代码。 Python 程序员不需要警告他们不小心插入了三字符组，或者类型双关的指针，因为他们没有精神病预处理器，也没有基于严格别名的优化。