【问题标题】:A language that satisfies this criteria?满足此标准的语言?
【发布时间】:2012-04-22 10:12:34
【问题描述】:

我也做过一些 Java 编程和很少的 C 和 PHP 编程。最近我开始学习 Python,因为它看起来很有趣。

但是一些关于 SO 的帖子似乎指出 Python 不适合并发编程。并且与那些具有编译器的语言相比也更慢。我也喜欢静态类型语言的优点,但 Python 是动态类型的。所以我的问题是,是否存在满足以下标准的语言。

1) 有一个解释器(为了更快的开发)

2) 有编译器(因为编译后的代码会运行得更快)

3) 具有面向对象的能力

4) 静态类型

我遇到了满足上述条件的 OCaml。但是 SO 上的帖子让我相信 OCaml 不适合并发编程。所以第五个标准是

5) 适合并发编程。

PS :- 我不是编程语言方面的专家,如果上述任何观察结果有误,请多多包涵。

【问题讨论】:

  • 解释器并不能保证更快的开发。
  • ...以“J”开头,以“a”结尾,有四个字母?
  • 您可以考虑ScalaErlangHaskell
  • OCaml 非常适合并发编程。也许您的意思是当前官方的运行时实现不支持 SMP parallelism - 这是真的。

标签: python programming-languages ocaml interpreter static-typing


【解决方案1】:

Python 可以满足除了静态类型之外的大部分需求,但是,由于它的设计,它具有称为 GIL 或 Global Interpreter Lock 的东西。这意味着 python 线程并没有真正单独执行。这可能解释了您谈到的关于 python 和并发编程的批评。但是,python 有 multiprocessing 模块,它提供了一个 api 来使用像线程这样的进程。同样,在不同 vm 下运行的 python 实现也没有 GIL,如果您已经熟悉 Java,也许您应该研究一下 Jython,它是一个在 JVM 上运行的 python 实现。

另外,虽然不是很明显,但值得注意的是 Python 确实可以编译为字节码。它在第一次导入任何脚本时执行此操作,这意味着如果编辑并导入 python 源文件,它会编译一次,所有进一步尝试导入同一模块的尝试都使用字节编译版本,并且不会重新执行脚本。这种行为更像是 java 而不是 PHP,它在每次运行时都会重新解释源代码。

【讨论】:

  • 另外,还有stackless.com Python——与最常见的C-python形成对比。存在 Python 的其他变体,在这种情况下,无堆栈 Python 旨在通过 Python 语言的优雅来准确解决并发问题。
  • 还要注意,您需要本机线程或多个进程才能利用多个内核,因此实际上 python 的限制对性能几乎没有影响。
【解决方案2】:

我想介绍三种语言,它们可能在很大程度上满足您正在寻找的所有功能

  1. 哈斯克尔

    • 有解释器(用于更快的开发):Ghci 和 Hugs 解释器
    • 有一个编译器(因为编译后的代码会运行得更快):Glasgow Haskel 编译器
    • 具有OO能力:在一定程度上,请阅读文章Haskell vs OOP
    • 静态类型:是的,不需要类型声明
    • 适合并发编程。:Yes, of course
  2. 二郎

    • 有解释器(用于加快开发):按照 Erlang 的工作方式,您可能没有 REPL,但解释器并非总是可以帮助加快开发。但在某种程度上,您可以使用erl
    • 有编译器(因为编译后的代码会运行得更快):是
    • 具有 OO 功能:没有,但有可用的实验性扩展。但如果你是在 Erlang 中开发,你最好坚持使用函数式编程
    • 静态类型:否
    • 适合并发编程:是的,这就是 Erlang 的著名之处。
  3. 时髦

    • 有解释器(用于更快的开发):是的
    • 有编译器(因为编译后的代码会运行得更快):是的
    • 具有 OO 功能:是的,毕竟它基于 Java
    • 静态类型:否
    • 适合并发编程:是的,继承自Java。

终于

  • Java 有一个叫做 BeanShell 的东西,它可以用作 Java 解释器,如果这就是阻止你使用 Java 的原因。

  • 您在 Python 中有 twisted 来为语言添加并发性。

如果您想进一步研究,请使用以下 wiki 链接

【讨论】:

    【解决方案3】:
    1. 学习 Scala。
    2. 如果不满意并且愿意使用 MS Visual Studio,请学习 F#。
    3. 如果不满意并且您可以重新考虑您的观点 (3),请学习 Haskell。
    4. 如果不满意并且您可以重新考虑您的观点 (5),请学习 OCaml。

    请注意,OCaml 程序可以相对轻松地跨单独的进程工作,因为它甚至可以编组闭包。

    【讨论】:

      【解决方案4】:

      是的,OCaml 适合并发编程。它确实有一个 Thread 模块,允许您像在 Java 中那样编写网络应用程序。

      请注意,它目前不支持真正的并行性(您不会有两个线程并行运行 OCaml 代码),但这并不重要,因为 OCaml 比许多其他语言快得多(例如,在 QuadCore 上, Language Shootout 表明 OCaml 在多核能力方面甚至优于 Haskell)。

      【讨论】:

        【解决方案5】:

        OCaml 适合并发编程。标准库支持两种concurrency 模型:具有共享内存的线程(使用mutexescondition variables 进行同步),以及基于John Reppy's Concurrent MLevents

        OCaml 不支持对称多处理器并行。运行时在单个处理器上执行。如果您想利用多核机器,您需要为每个处理器运行至少一个运行时,并在运行时之间使用消息传递。消息传递具有更高的延迟,但比共享内存更难正确传递。作为奖励,程序可以分布在网络上的多台机器上,除了运行时启动时找到彼此的方式之外,无需更改任何内容。

        JoCaml 是 OCaml 的扩展,具有更好的并发和分布模型(join calculus)。它不像官方 OCaml 发行版那样精巧,但具有提供透明通信(在通道上发送消息而不必担心对方是否在同一运行时甚至在同一台机器上)和主要类型化的通信框架的优势多个程序之间。

        【讨论】:

          【解决方案6】:

          根据您的意思,适合并发编程我会推荐 OCaml 或 SML(标准 ML):

          1. 无需等待 I/O 的多线程(网络/文件系统/..);以 OCaml 为例——它的编译器生成非常快的代码并拥有许多优秀的库
          2. 如果并发意味着允许您在同一共享内存段内的一台机器上使用多个内核的本机线程;以 SML (polyml) -- 它有一个不错的编译器并支持本机线程

          请注意,无论哪种解决方案,您都将开始使用类型推断!一旦你习惯了,用任何语言编程都会让你哭泣! ;)

          【讨论】:

            【解决方案7】:

            首先考虑其他资源更为重要。

            1) 有一个解释器(为了更快的开发) - imo un true

            2) 有编译器(因为编译后的代码会运行得更快)——真的吗?开发和服务器机器和部署上的不同拱门呢?

            3) 具有 OO 功能 - 为什么?函数式语言更适合并行编程

            4) 静态类型 - 为什么?如果它在类型系统中具有“null”值,那么这与非静态类型的 imo 之间没有区别。

            更好的标准是

            1. 有多少优质库和框架供您使用。
            2. 您将如何部署此解决方案
            3. 让新开发人员加入您的项目是多么容易
            4. 社区的质量如何:)

              • Ocaml 是一门很棒的语言,使用 Lwt 库,即使只有一个进程很容易,您也可以编写异步代码。 Ocaml 也非常快!这似乎是不错的解决方案,但您没有很多可用于生产的框架。

              • Erlang 有库,它很酷,速度很快,似乎是满足您需求的最佳解决方案。

              • Ruby 和 Ruby On Rails 无法让您轻松编写并发代码,但您将能够快速构建解决方案并开始从中赚钱 :) 我的意思是比其他语言快 10 倍,因为您有准备好的块。在这种情况下,部署也是最简单的。

              • Node.js 速度快,易于上手的语言 (javascript),但处于开发的早期阶段,因此生产就绪的东西不多。

            现在这就是我处理解决方案的方式:

            就性能而言,你有一个交易

            1. 内存上限
            2. CPU 上限

              • 内存上限 (ram) 意味着用这种语言编写的解决方案将消耗越来越多的 ram,最终您将不得不快速购买新盒子,并且要扩展的盒子必须“胖”:)
              • CPU 上限意味着该解决方案具有真正积极的垃圾收集器并分配大量经常清理的小对象。

            在这种情况下,Node.js 和 Rails 是有内存上限的,Rails 在生产中每个工人平均消耗大约 250mb 的内存。 Ocaml / Oscigen , Erlang / Webmachine 是 CPU 上限的,大多数函数式语言都会走这条路。

            我在 i5 CPU https://gist.github.com/1996858 的 macbook pro 上对 webmachine 进行了小测试 该资源提供了每次从 redis 中提取的简单 json,没有缓存。

            100 万个请求 总计:连接 1000 个请求 1000000 个回复 1000000 个测试持续时间 463.413 s

            Connection rate: 2.2 conn/s (463.4 ms/conn, <=1 concurrent connections)
            Connection time [ms]: min 390.6 avg 463.4 max 3245.7 median 453.5 stddev 101.6
            Connection time [ms]: connect 0.1
            Connection length [replies/conn]: 1000.000
            
            Request rate: 2157.9 req/s (0.5 ms/req)
            

            现在最好的部分是监控内存使用情况。它大约是 19.3 mb 内存。

            如果你问我,我会在 Rails 中构建应用程序原型,然后提取 json api 并使用 webmachine 在 Erlang 中构建它们。或者只是使用 webmachine 在 Erlang 中构建应用程序,然后使用一些 ruby​​ 库的一些不错的功能,如 capistrano 进行部署:)

            【讨论】:

              猜你喜欢
              • 1970-01-01
              • 2013-02-05
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 1970-01-01
              • 2016-02-29
              • 1970-01-01
              相关资源
              最近更新 更多