可以将静态和动态类型的语言视为用于不同类型工作的不同工具吗？

是的，曾经提出过类似的问题，但总的目的是找出“哪个更好”。

我之所以这样问是因为我最初是作为一名开发人员来使用JavaScript的，并且实际上并没有在使用静态类型语言编写方面的丰富经验。

尽管如此，我肯定会发现学习C语言在较低级别的代码上处理苛刻的操作的价值（我认为这在编译器级别与静态与动态有很大关系），但是我想尽力而为是否存在特定的项目上下文（也许是某些类型的动态数据密集型操作？）涉及性能以外的其他方面，因此与Java或C＃相比，与Python之类的东西更有意义。

当然是。
在您希望能够将所有内容都视为一种类型的情况下，动态类型化具有绝对的优势。序列化/反序列化是经典示例之一。这就是为什么这么多的Web编程是用动态类型的脚本语言完成的原因：它们非常适合一项涉及大量数据在字符串之间来回转换的任务。

另一方面，对于应用程序编程，静态语言的效果要好得多，因为尝试将所有内容都视为一种单一类型并不是经常需要的。您通常希望拥有高效的数据结构，并且将数据表示为自身，而不是非常频繁地转换为其他类型。这使动态类型化功能成为缺点而不是优点，这就是为什么应用程序几乎完全用静态类型化语言编写的原因。

我的看法是，如果您可以在静态类型的语言中自然地工作，那么静态类型就是可行的方法。通常，类型系统的目的是防止您使用未定义的语义（例如）执行操作(string) "hello" + (bool) true。即使没有进行大量的单元测试，具有防止您执行这些操作的额外安全级别也是防止代码中错误的好方法。也就是说，类型安全性对代码的语义正确性提供了另一种置信度。

但是类型系统很难正确处理。我不相信有是在写这篇文章的时候了完善的类型系统的性质。（“完美类型系统”是指严格的类型系统，它不需要冗长的代码注释，不会产生假阳性的类型错误，并且程序员易于理解其类型错误。）此外，它还可以很难理解确实存在的真正好的类型系统。当我学习Haskell时，我无法告诉您尝试写对我来说看起来像正确代码的代码时出现的模糊类型错误的数量。通常，代码实际上是不正确的（这是对类型系统的支持），但是花了很多时间工作，以了解来自编译器的错误消息，以便我可以更正潜在的问题。在OO语言中，您可能最终会发现自己在想“此参数应与输入类型相反，而不是协变！”，或者（更有可能）恢复为类型转换以逃避类型系统的范围。类型系统比您想象的要棘手得多。

对于它的价值，我的理解是，提出好的类型系统的困难是促使Gilad Bracha在Newspeak中加入可插拔类型系统支持的部分原因。

它们是不同的工具，但不是根据性能。这都是关于复杂性的。

动态语言通常以最大的灵活性为目标，并且带来了缺乏验证和某种保证的情况。然后，它在小型程序中非常强大，但是维护大型程序（复杂性）几乎变得不可能。

静态语言通常旨在最大程度地验证。他们的首要目标通常是尽早发现错误（或错误）。为验证提供了很多保证。这样一来，学习和启动起来就更加困难，但是随着程序的扩大，它可以以更少的成本（编码工作量）提供更好的程序验证。

结果，动态语言通常适合小型（我的意思是很小）程序，例如动态网页，Web浏览器DSL（不适用于浏览器应用程序！）或Shell脚本。静态语言更适合于系统编程或其他任何东西。

上面的描述是关于非常纯动态或静态语言的。大多数现实生活中的语言都在它们之间，并且表现出各种特征。

请参阅此处以获取更多详细信息：https : //softwareengineering.stackexchange.com/a/105417/17428

我目前使用静态类型语言（C＃和F＃）进行编程，但是我喜欢使用动态语言（Smalltalk，Ruby）进行编程。人们将一种类型与另一种类型相关联的利弊很多，而与强制实施类型相比，更多的是关于语言的。例如，动态语言通常具有更简洁明了的语法，但是F＃和OCaml及其类型推断系统的语法与任何动态语言一样干净。有了静态类型，您便具有真正的自动重构和自动完成功能，但是Smalltalk以及数据库中的全部源代码和单独编译的每种方法，是真正具有认真的自动重构功能的第一门语言，而且效果很好。最终，当今的现代动态和静态语言都是类型安全的，这是类型系统中最重要的方面，

现在是2015年，在对话中添加了一些有趣的摘要：

1. 企业后端世界的重要部分正在考虑或开始使用Python（动态）代替Java（严格为静态）
2. 企业前端世界正在看到基于TypeScipt的AngularJS v2之类的东西：TypeScipt 是Javascript 的类型化扩展。

因此，后端人员厌倦了不必要的严格打字，而前端人员厌倦了动态打字的混乱。

颇具讽刺意味的是：我想知道他们是否会在中间相遇，或者随着截止日期过去的声音热潮相互冲撞……？;）