Scala 中缺少动态语言(如 Ruby 或 Clojure)的哪些功能?

发布于 2024-08-27 16:06:17 字数 366 浏览 8 评论 0原文

当您选择 Scala(或 F#、Haskell、C#)等静态类型语言而不是 Ruby、Python、Clojure、Groovy(具有宏或运行时元编程功能)等动态类型语言时,您在实践中会损失什么?请考虑最好的静态类型语言和最好的(在您看来)动态类型语言,而不是最差的语言。

答案摘要

与 Scala 等静态类型语言(恕我直言)相比,Ruby 等动态语言的主要优点是:

  • 快速编辑运行周期(JavaRebel 是否缩小了差距?)
  • 目前 Scala/Lift 的社区规模要小得多Ruby/Rails 或 Python/Django
  • 可以修改类型定义(尽管动机或需求不是很清楚)

What do you lose in practice when you choose a statically-typed language such as Scala (or F#, Haskell, C#) instead of dynamically-typed ones like Ruby, Python, Clojure, Groovy (which have macros or runtime metaprogramming capabilities)? Please consider best statically-typed languages and best (in your opinion) dynamically-typed languages, not the worst ones.

Answers Summary:

Key advantages of dynamic languages like Ruby over statically-typed language like Scala IMHO are:

  • Quick edit-run cycle (does JavaRebel reduces the gap?)
  • Currently community of Scala/Lift is much smaller then of Ruby/Rails or Python/Django
  • Possible to modify type definitions (though motivation or need for that is not very clear)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(7

小傻瓜 2024-09-03 16:06:17

原则上,当不清楚(在静态上下文中)正确的做法是什么时,您就放弃了忽略您正在使用的类型,仅此而已。

由于复杂的类型检查可能相当耗时,因此您也可能被迫放弃快速在线元编程。

在实践中,使用 Scala,您几乎不需要放弃任何其他东西,也没有什么我特别关心的东西。您无法注入新方法,但可以编译并运行新代码。您确实必须在函数参数中指定类型(以及递归函数的返回类型),如果您自己从不犯类型错误,这会有点烦人。由于它编译每个命令,因此 Scala REPL 不像 Python shell 那样敏捷。而且由于它使用 Java 反射机制,因此您无法像使用 Python 那样轻松地进行在线检查(无论如何,不​​是不构建自己的检查库)。

In principle, you give up being able to ignore what type you're using when it is not clear (in the static context) what the right thing to do is, and that's about it.

Since complex type-checking can be rather time-consuming, you also probably are forced to give up fast on-line metaprogramming.

In practice, with Scala, you give up very little else--and nothing that I particularly care about. You can't inject new methods, but you can compile and run new code. You do have to specify types in function arguments (and the return type with recursive functions), which is slightly annoying if you never make type errors yourself. Since it compiles each command, the Scala REPL isn't as snappy as e.g. the Python shell. And since it uses Java reflection mechanisms, you don't have quite the ease of online inspection that you do with e.g. Python (not without building your own inspection library, anyway).

夏九 2024-09-03 16:06:17

选择静态或动态语言比静态/动态选择本身更重要。一些动态语言具有良好的性能和良好的工具。一些静态语言可以是简洁的、富有表现力的和增量的。有些语言几乎没有这些品质,但确实拥有大量经过验证的代码库。

The choice of which static or dynamic language is more significant than the static/dynamic choice itself. Some dynamic languages have good performance and good tools. Some static languages can be concise, expressive, and incremental. Some languages have few of these qualities, but do have large libraries of proven code.

想你的星星会说话 2024-09-03 16:06:17
  1. 动态语言往往具有更灵活的类型系统。例如,Python 允许您将新方法注入到现有的类中,甚至注入到单个对象中。
  2. 许多(不是全部)静态语言缺乏构造复杂文字的功能。例如,C# 和 Java 等语言无法轻松模仿以下 JavaScript { 'request':{'type':'GET', 'path':mypath}, 'oncomplete':function(response) {alert(response) .结果)} }
  3. 动态语言具有非常流畅的语义。 Python 允许导入语句、函数定义和类定义出现在函数和 if 语句内。
  4. eval 是大多数动态语言和少数静态语言的主要内容。
  5. 由于必须完全指定函数参数类型的尴尬,动态语言中的高阶编程比静态语言更容易(以我的主观观点)。
    • 对于递归 HOP 结构尤其如此,其中类型系统确实会造成妨碍。
  6. 动态语言用户不必处理协变和逆变。
  7. 动态语言中的通用编程实际上是免费的。
  1. Dynamic languages tend to have much more flexible type systems. For example, Python lets you inject a new method into an existing classes, or even into a single object.
  2. Many (not all) static languages lack the facility to construct complex literals. For instance, languages like C# and Java cannot easily mimic the following JavaScript { 'request':{'type':'GET', 'path':mypath}, 'oncomplete':function(response) { alert(response.result) } }.
  3. Dynamic languages have very fluid semantics. Python allows import statements, function definitions and class definitions to appear inside functions and if statements.
  4. eval is a staple of most dynamic languages and few static languages.
  5. Higher order programming is easier (in my subjective opinion) in dynamic languages than static languages, due to the awkwardness of having to fully specify the types of function parameters.
    • This is particulary so with recursive HOP constructs where the type system can really get in the way.
  6. Dynamic language users don't have to deal with covariance and contravariance.
  7. Generic programming comes practically free in dynamic languages.
披肩女神 2024-09-03 16:06:17

我不确定除了简单性之外你是否会失去任何东西。静态类型系统是学习的额外负担。

我想你通常也会丢失eval,但我从不使用它,即使在动态语言中也是如此。

我发现,当涉及到为给定任务选择使用哪种语言时,问题更多的是其他方面。当涉及到用语言解决问题时,工具、文化、库都比打字有趣得多。

另一方面,编程语言研究则完全不同。 :)

I'm not sure if you lose anything but simplicity. Static type systems are an additional burden to learn.

I suppose you usually also lose eval, but I never use it, even in dynamic languages.

I find the issue is much more about everything else when it comes to choosing which language to use for a given task. Tooling, culture, libraries are all much more interesting than typing when it comes to solving a problem with a language.

Programming language research, on the other hand, is completely different. :)

想你只要分分秒秒 2024-09-03 16:06:17

Steve Yegge 此处表达了对 Scala 的一些批评< /a> 和此处,以及 Guido van Rossum,主要攻击 Scala 类型系统的复杂性。但他们显然不是“Scala 程序员”。另一方面,这里有一些 来自 James 的赞扬斯特拉坎。

Some criticism of Scala has been expressed by Steve Yegge here and here, and by Guido van Rossum, who mainly attacked Scala's type system complexity. They clearly aren't "Scala programmers" though. On the other hand, here's some praise from James Strachan.

烦人精 2024-09-03 16:06:17

我的 2 美分...

IMO(强)静态类型语言可能会减少必要的测试代码量,因为其中一些工作将由编译器完成。另一方面,如果编译步骤相对较长,那么“增量式”编程就会变得更加困难,这在现实生活中可能会导致容易出错的代码,而这些代码只是经过编译器测试才通过的。

另一方面,动态类型语言感觉改变事物的门槛较低,这可能会减少错误修复和改进的响应时间,因此可能会在应用程序开发过程中提供更平滑的曲线:处理常量小变更的流程比处理 bug 块中的变更更容易/风险更小。

例如,对于设计非常不清楚并且应该经常更改的项目,如果有助于减少不同部分之间的相互依赖性,那么使用动态语言可能比使用静态语言更容易。 (不过我并不坚持这一点:))

我认为 Scala 介于两者之间(例如,您不必显式指定变量的类型,与 C++ 相比,这可能会简化代码维护,但如果您最终得到关于类型的错误假设,编译器会提醒它,这与 PHP 不同,在 PHP 中你可以编写任何内容,如果你没有很好的测试来覆盖功能,那么当一切都活跃起来时,你注定会发现它)。当然可能是非常错误的:)

My 2 cents...

IMO (strong) statically-typed languages might reduce the amount of necessary testing code, because some of that work will be done by the compiler. On the other hand, if the compiling step is relatively long, it makes it more difficult to do "incremental-style" programming, which in the real life might result in error-prone code that was only tested to pass the compiler.

On the other hand, dynamically-typed languages feel like there is less threshold to change things, that might reduce the responding time from the point of bug-fixing and improvement, and as a result might provide a smoother curve during application development: handling constant flow of small changes is easier/less risky than handling changes which are coming in bug chunks.

For example, for the project where the design is very unclear and is supposed to change often, it might have been easier to use dynamic language than a static one, if it helps reduce interdependencies between different parts. (I don't insist on that one though:) )

I think Scala sits somewhere in between (e.g. you don't have to explicitly specify types of the variables, which might ease up code maintenance in comparison with e.g. C++, but if you end up with the wrong assumption about types, the compiler will remind about it, unlike in PHP where you can write whatever and if you don't have good tests covering the functionality, you are doomed to find it out when everything is live and bleeding). Might be terribly wrong of course :)

梨涡少年 2024-09-03 16:06:17

在我看来,静态类型和动态类型之间的差异归结为编码风格。尽管 Scala 中有结构类型,但大多数时候程序员都会根据对象的类型来思考,包括 Trait 等很酷的小工具。另一方面,我认为 Python/Javascript/Ruby 程序员是根据对象的原型(方法和属性列表)来思考的,这与类型略有不同。

例如,假设有一个名为 Vehicle 的类系列,其子类包括 PlaneTrainAutomobile;另一个类系列称为 Animal,其子类包括 CatDogHorse。 Scala 程序员可能会创建一个名为 Transportation 的特征或具有

def ride: SomeResult
def ride(rider: Someone): SomeResult

成员的东西,这样她就可以处理 TrainHorse 作为一种手段的交通。 Python 程序员只需传递 train 对象,无需额外代码。在运行时,语言发现该对象支持ride

由于方法调用是在运行时解析的,因此 Python 和 Ruby 等语言可以拥有重新定义属性或方法含义的库。一个很好的例子是 O/R 映射或 XML 数据绑定,其中未定义的属性名称被解释为表/XML 类型中的字段名称。我想这就是人们所说的“灵活性”。

根据我使用动态语言的非常有限的经验,我认为只要不犯错误,使用动态语言编码会更快。也许当您或您的同事擅长使用动态语言进行编码时,他们会犯更少的错误或开始编写更多的单元测试(祝您好运)。根据我有限的经验,我花了很长时间才发现动态语言中的简单错误,而 Scala 可以在一秒钟内捕获。在编译时拥有所有类型也使重构变得更加容易。

In my opinion, the difference between the static and dynamic typing comes down to the style of coding. Although there is structural types in Scala, most of the time the programmer is thinking in terms of the type of the object including cool gadgets like trait. On the other hand, I think Python/Javascript/Ruby programmers think in terms of prototype of the object (list of methods and properties), which is slightly different from types.

For example, suppose there's a family of classes called Vehicle whose subclasses include Plane, Train, and Automobile; and another family of classes called Animal whose subclasses include Cat, Dog, and Horse. A Scala programmer would probably create a trait called Transportation or something which has

def ride: SomeResult
def ride(rider: Someone): SomeResult

as a member, so she can handle both Train and Horse as a means of transportation. A Python programmer would just pass the train object without additional code. At the run time the language figures out that the object supports ride.

The fact that the method invocations are resolved at the runtime allows languages like Python and Ruby to have libraries that redefines the meaning of properties or methods. A good example of that is O/R mapping or XML data binding, in which undefined property name is interpreted to be the field name in a table/XML type. I think this is what people mean by "flexibility."

In my very limited experience of using dynamic languages, I think it's faster coding in them as long as you don't make mistakes. And probably as you or your coworkers get good at coding in dynamic language, they would make less mistakes or start writing more unit tests (good luck). In my limited experience, it took me very long to find simple errors in dynamic languages that Scala can catch in a second. Also having all types at compile time makes refactoring easier.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文