language-agnostic - 动态语言在现实生活中的好处?

标签 language-agnostic dynamic-languages

我正在探索开发新系统(Web 应用程序)的几种可能性。

我是一个“老式”的人,本质上是面向对象的(从多年前的程序转换而来)。我玩过 Python 并学习了一点 Ruby,但坦率地说,我对使用 Microsoft 的工具(C#、ASP.NET MVC)很感兴趣。在构建大型复杂应用程序时,所有这些运行时输入、基本内容上没有编译器错误等等只会让我的生活更加艰难。

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

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

最佳答案

我的经验

我和两者都共事过,可能每个专业都有大约十年的时间。

有趣的是,我花了更多的时间试图让静态类型语言理解我想要做什么(可能是几周 - 可能总共几个月),而不是我花在修复由动态类型错误引起的错误上(可能一年一两个小时? )。

学习

人们已经非常努力地获得证据表明其中一个或另一个在程序员生产力方面更好,但我读过的最新评论说没有有力的证据证明这两者。

极权主义

静态类型分析在某些情况下很有用。我认为它不应该天生就融入你的语言。它应该是您的交互式计算环境中的一个工具,以及您的测试、REPL、重构、文档、文字编码等。

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

限制性太强和限制性不够

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

相反,为什么不使用基础动态语言来描述类型和类型系统呢?作为图书馆。它更具表现力;更强大(如果需要);更灵活;并且意味着更小的基础语言。

样板

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

单片

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

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

我们应该为整体构建微小的扩展,而不是着手构建新的整体应用程序,因此这种单一趋势,如果存在的话,是有害的。

速度

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

长期

我怀疑从长远来看,我们最终会得到支持强大静态分析的环境,您可以在其中声明类型和协议(protocol),系统将帮助您查看它们是否满意,或帮助您显示隐含的类型。但你不需要这样做。

关于language-agnostic - 动态语言在现实生活中的好处?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/1043293/

相关文章:

c++ - 没有括号的 if 语句是否更快?

unit-testing - 什么是 "Unit"?

c# - C# 4.0 中使用动态类型的重载解析

c# - 学习 DLR(如何在其上实现一种语言)

dynamic-languages - 脚本编写者是否必须考虑舍入误差?

algorithm - 包含 x% 点的最小包围球

math - float 学有问题吗?

java - 当我的 AI 试图收集点数时,我的收集算法有什么问题?它变得困惑,来回走动

ioc-container - 为什么动态语言不需要 IOC 容器

python - 调试 Ruby/Python/Groovy