朱莉娅有希望加入统计界吗？

我最近阅读了R-Bloggers的一篇文章，该帖子与John Myles White的这篇博客文章相关，该文章涉及一种名为Julia的新语言。朱莉娅需要一个刚刚即时编译器，给它邪恶的快速运行时间，并把它的速度C / C ++（相同的数量级相同的数量级上的优势秩序，不是同样快）。此外，它使用我们开始使用传统语言进行编程的人们所熟悉的正统循环机制，而不是R的apply语句和向量运算。

即使茱莉亚如此出色的时机，R也不会消失。它在行业中具有广泛的支持，并且有许多出色的软件包可以执行任何操作。

我的兴趣是本质上的贝叶斯（Bayesian），在这种情况下通常不可能进行矢量化。当然，串行任务必须使用循环来完成，并且每次迭代都需要大量的计算。在执行这些串行循环任务时，R可能会非常慢，并且C / ++并不是编写程序的第一步。Julia似乎是用C / ++编写的一种很好的替代方法，但是它还处于起步阶段，并且缺少许多我喜欢R的功能。只有获得足够的支持，将Julia作为计算统计工作台来学习才有意义。来自统计界的人，人们开始为此编写有用的软件包。

我的问题如下：

1. 朱莉娅需要具有什么特征才能具有使R成为事实统计语言的吸引力？

2. 与学习诸如C / ++这样的低级语言相比，学习Julia来执行大量计算任务有什么优点和缺点？

我认为关键在于是否开始为Julia开发库。看到玩具示例（即使它们是复杂的玩具）也很好，这很好，证明茱莉亚在任务R不好的情况下将R吹出了水。

但是我做过很多使用R的人，为什么循环和手工编码算法做得不好，并不是为什么我会使用R。他们之所以使用R，是因为几乎在阳光下进行的任何统计任务都有人为其编写R代码。R既是一种编程语言，又是一种统计数据包-目前，Julia只是前者。

我认为有可能实现这一目标，但是还有更多的成熟语言（Python）仍在努力成为可用的统计工具包。

我同意其他许多意见。“希望”？当然。我认为Julia多年来从R和Python / NumPy / Pandas以及其他系统所做的对与错中学到了很多东西。如果我比以前聪明，并且想写一种新的编程语言作为将来的统计开发环境的基础，那么它看起来就很像Julia。

这就是说，事后才可能回答这个问题还需要5年。到目前为止，Julia缺少统计编程系统的以下关键方面，这些系统可能与R竞争日常用户：

（列表随时间更新...）

• 可选排序的因子类型
• 大多数统计检验和统计模型
• 识字编程/可复制分析支持
• R级甚至Matlab级绘图

为了与R竞争，Julia和附加统计信息包必须足够干净和完整，以使聪明的非程序员（如社会科学专业的研究生）可以合理地使用它。要达到目标，需要进行大量的工作。也许会发生，也许会失败，或者其他一些（R 3.0？）将取代它。

更新：

Julia现在支持缺少数据/ NA，模块/命名空间，formula类型和model.matrix基础结构，绘图（排序），数据库支持（但尚未支持DataFrame）以及通过关键字传递参数的DataFrame。现在还提供一个IDE（Julia Studio），Windows支持，一些统计测试以及一些日期/时间支持。

对我而言，数据分析语言的一个非常重要的事情是具有查询/关系代数功能以及合理的默认值和面向交互的设计，并且理想情况下，这应该是该语言的内置功能。IMO，我使用过的任何FOSS语言都无法有效地做到这一点，甚至R也没有。

data.frame很难以交互方式进行处理-例如，它在调用时打印整个数据结构，$语法很难以编程方式使用，查询需要冗余的自引用（即DF[DF$x < 10]），联接和聚合很尴尬。Data.table解决了大多数此类烦恼，但由于它不是核心实现的一部分，因此大多数R代码都没有利用其功能。

python中的熊猫也遭受相同的错误。

这些问题看似挑剔，但这些缺陷会累积起来，最终总的来说是很重要的，因为它们要花费大量时间。

我相信，如果Julia要在数据分析环境中取得成功，就必须致力于在用户友好的表数据类型上实现SQL类型运算符（不占用SQL语法）。

我可以按照Dirk和EpiGrad的话签名。然而，还有另一件事使R在其利基市场中成为独特的语言-面向数据的类型系统。

R是专门为处理数据而设计的，这就是为什么它以向量为中心并且具有诸如data.frames，factors，NAs和attribute之类的东西。
另一方面，Julia的类型是面向数字性能的，因此我们具有标量，定义明确的存储模式，联合和结构。

这看起来似乎是无害的，但是所有尝试使用MATLAB进行统计的人都知道这确实很痛苦。

因此，至少对于我来说，Julia无法提供我无法用几行C块修复的任何内容，并且杀死了许多真正有用的表达方式。

我可以看到Julia取代了Matlab，这对人类来说将是一项巨大的服务。

要替换R，您需要考虑Neil G，Harlan和其他人提到的所有内容，以及一个我认为没有解决的重要因素：易于安装应用程序及其库。

现在，您可以为Mac，Windows或Linux下载R的二进制文件。它具有大量的统计方法开箱即用的功能。如果要下载软件包，只需简单的命令或单击鼠标即可。它只是工作。

我去下载了Julia，这并不简单。即使下载二进制文件，也必须安装gfortran才能获得正确的库。我下载了源并尝试下载make，但没有任何有用的消息，但失败了。我拥有计算机科学的本科和研究生学位，所以如果我愿意的话，我可以四处找寻并开始工作。（我不是。）乔统计学家会这样做吗？

R不仅有大量的软件包可供选择，它还具有相当成熟的系统，可以自动生成应用程序和几乎所有软件包的二进制文件。如果由于某种原因需要从源代码编译软件包，则实际上并没有什么困难（只要您在系统上安装了适当的编译器等）。您不能忽略此基础架构，通过github进行所有操作，并期望得到广泛采用。

编辑：我想和朱莉娅混在一起-看起来很激动。两个问题：

1）当我尝试安装其他软件包（忘记它们在Julia中的名称）时，它失败并出现模糊的错误。显然，我的Mac没有他们期望的make-like工具。它不仅会失败，而且还会留下我必须手动删除的内容，否则其他安装将失败。

2）它们在一行代码中强制一定的间距。我前面没有细节，但是它与宏有关，并且在宏和括号之间没有空格以打开其参数。这种限制确实让我感到烦恼，因为我已经开发了多年的代码格式和语言，而且实际上在函数/宏名称和左括号之间留了一个空格。我了解一些代码格式限制，但是一行中是否包含空格？

朱莉娅语言很新。它在聚光灯下的时间可以用几周来度量（即使它的显影时间当然可以用数年来度量）。现在，这些星期是非常激动人心的几周-例如，在斯坦福大学最近的演讲“它才刚刚开始”-但您在更广泛的基础架构和软件包支持方面的要求将花费更长的时间实现。

因此，我将继续使用R，并注意开发替代方案。去年，有很多人对Clojure进行抗议。今年朱莉娅（Julia）是盛行的新口味。我们看看它是否粘住。

布鲁斯·泰特（Bruce Tate），《七周七种语言》的作者。这里有一些想法。我正在为Julia编写后续书籍。以下是我玩了几周后的看法。

有两个基本作用力在起作用。首先，所有语言都有生命周期。R将有一天被替换。我们不知道什么时候。新语言的发展非常困难。当一种新语言发展起来时，通常可以解决一些压倒性的痛点。

这两件事是相关的。对我来说，我们开始看到围绕R之类的语言正在形成一个主题。它不够快，而且比所需的要难。那些可以在特定性能范围内生活并留在已建立的库中的人很好。那些不需要更多的人，他们开始寻找更多的东西。

事实是，计算机体系结构正在发生变化，并且要利用它们，必须以某种方式构建语言及其结构。Julia对并发的看法很有趣。它为这种语言优化了正确的选择：透明分发和进程之间数据的有效移动。当我将Julia用于典型任务，映射和转换等时，我只是在调用函数。我不必担心管道问题。

对我来说，Julia在一个处理器上更快的事实很有趣，但对R而言却不是太过分。对我而言，有趣的是，随着处理器越来越依赖多核来提高性能，技术计算问题几乎处于理想的位置。运用正确的语言，以发挥最大的优势。

可以帮助实现此目标的另一个功能确实是宏。目前语言的节奏非常紧张。宏使您可以使用更大，更干净的构建块进行构建。查看库很有趣，但并不能说明全部情况。您需要查看库的增长。朱莉娅的轨迹就在这里。

Clojure对某些人来说很有趣，因为没有R能做的技术语言，因此有些人希望通用语言来填补这一空白。我实际上是个超级粉丝。但是Clojure是一个非常严重的大脑扭曲。Clojure将提供给需要进行技术计算的程序员。它不适合工程师和科学家。有太多东西要学。

因此对我来说，Julia或类似的东西绝对有一天会取代R。这是时间问题。

每当我看到一种新的语言时，我都会问自己为什么不能改善现有的语言。

Python的最大优势是

• 丰富的模块集（不仅是统计信息，还包括绘图库，输出为pdf等）
• 您最终需要长期使用的语言构造（大型项目中需要的面向对象构造；装饰器，闭包等可简化开发）
• 许多教程和庞大的支持社区
• 如果您有大量数据要处理，并且不介意花几分钱在集群上运行它，则可以访问mapreduce。

为了超越R，Julia等，Python可以使用

• 针对受限Python进行即时编译的开发，以在一台机器上为您提供更高的速度（但如果您能够承受延迟，则mapreduce仍然更好）
• 丰富的统计资料库

朱莉娅不会很快接管R。签出Microsoft R打开。

https://mran.revolutionanalytics.com/open/

这是R的增强版本，可自动使用计算机的所有核心。它是相同的R，相同的语言，相同的软件包。安装时，RStudio还将在控制台中使用它。MRO的速度甚至比Julia还要快。我做了很多重型计算，并且已经使用Julia一年多了。我最近改用R是因为R有更好的支持，而RStudio是很棒的编辑器。Julia仍处于初期阶段，可能很快就无法赶上Python或R。

以下内容可能不应该作为答案，但将其掩盖为对他人的回应进行评论太重要了...

我没有听到太多关于内存消耗的信息，只是速度。R的整个语义都是按值传递的，这可能会很痛苦，而这一直是对该语言的一种批评（这与已经存在多少个出色的软件包是一个独立的问题）。良好的内存管理非常重要，具有处理核心外处理的方式（例如numpy的内存映射数组或pytables或Revolution Analytics的xdf格式）也很重要）。虽然PyPy的JIT编译器允许使用一些引人注目的Python基准测试，但内存消耗可能会很高。那么，有人对Julia和内存使用有经验吗？听起来好像Windows“ alpha”版本存在内存泄漏，这无疑将得到解决，而且我仍在等待访问Linux机器来自己使用该语言。

我认为，由于前面提到的许多原因，Julia不太可能会取代R。Julia是Matlab的替代品，而不是R的替代品。他们有不同的目标。甚至在朱莉娅拥有完备的统计资料库之后，也没人会在其中教授“统计概论”课程。

但是，令人难以置信的一个领域是作为一种速度优化的编程语言，它比C / C ++痛苦得多。如果将其无缝链接到R（采用Rcpp样式），那么它将在编写对速度要求严格的代码段中大量使用。不幸的是，目前没有这样的链接：

https://stackoverflow.com/questions/9965747/linking-r-and-julia

我是Julia新手，并且具备R能力。到目前为止，我发现Julia有趣的原因是性能和兼容性。

GPU工具。我想将CUSPARSE用于统计应用程序。CRAN结果表明那里没有太多东西。Julia有可用的绑定，到目前为止似乎可以正常工作。

using CUSPARSE
N = 1000
M = 1000
hA = sprand(N, M, .01)
hA = hA' * hA
dA = CudaSparseMatrixCSR(hA)
dC = CUSPARSE.csric02(dA, 'O') #incomplete Cholesky decomp
hC = CUSPARSE.to_host(dC)

HPC工具。一个群集可以与多个计算节点交互使用。

nnodes = 2
ncores = 12    #ask for all cores on the nodes we control
procs = addprocs(SlurmManager(nnodes*ncores), partition="tesla", nodes=nnodes)
for worker in procs
    println(remotecall_fetch(readall, worker, `hostname`))
end

Python兼容性。可以访问python生态系统。例如，很容易找出如何读取脑成像数据：

import PyCall
@pyimport nibabel

fp = "foo_BOLD.nii.gz"
res = nibabel.load(fp)
data = res[:get_data]();

C兼容性。下面的代码使用C标准库生成一个随机整数。

ccall( (:rand, "libc"), Int32, ())

速度。以为我会看到Distributions.jl包是如何针对R的rmrm进行的-我认为它是经过优化的。

julia> F = Normal(3,1)
Distributions.Normal(μ=3.0, σ=1.0)

julia> @elapsed rand(F, 1000000)
0.03422067

在R中：

> system.time(rnorm(1000000, mean=3, sd=1))
   user  system elapsed 
  0.262   0.003   0.266 

Julia 1.0刚刚推出了非常实用的IDE（Juno）。由于Python已经在机器学习中占据了主导地位，而R继续在所有其他类型的统计分析中占据主导地位，因此晚了一点。话虽如此，朱莉娅已经在金融和交易算法领域中脱颖而出，因为必须要有快速的开发时间和执行力。我认为，除非出现另一种明显更好的语言，否则Julia的显赫地位可能看起来像这样：

（1）开始吃MATLAB的午餐。MATLAB用户喜欢MATLAB语法，但几乎讨厌其他所有内容。速度慢，许可证昂贵，处理不是矩阵的复杂数据结构的方式非常有限。我记得有句名言说：“如果朱莉娅取代MATLAB，它将为人类提供巨大的服务”。MATLAB用户可以很快地熟练使用Julia，并且对编写质量比MATLAB所能做的事情要简单得多的高质量代码感到印象深刻（快速的结构可以放入数组中并快速迭代吗？）。不仅如此，研究人员还可以在Julia中创建严肃的工具箱（一个小团队的博士生编写了世界一流的微分方程组），而这在MATLAB中是不可能实现的。

（2）开始接管数值方法和模拟的研究。麻省理工学院正在大力支持朱莉娅，研究界也在倾听麻省理工学院的声音。数值模拟和新的数值方法是没有库的不确定问题。这就是茱莉亚语言的光芒。如果没有可用的库，那么用Julia编写快速质量的代码比任何其他语言都容易得多。这将是由数学家为数学家编写的数字/模拟语言（听起来与R相似吗？）

（3）机器学习的另一项突破使朱莉娅获得了优势。这有点通配符，可能不会发生。TensorFlow很棒，但是很难破解。Python已经开始显示出裂缝，而TensorFlow已经开始采用Swift（Julia获得了荣誉奖）。如果发生另一项机器学习突破，那么在Flux.jl之类的Julia包中实现和破解将更加容易。

（4）朱莉娅开始慢慢追上R，这需要一段时间。在MATLAB中进行统计非常痛苦，但是Juila在Distributions.jl方面已经领先于MATLAB。事实是，R工作流可以轻松转换为Julia。R唯一真正的优势是，统计人员为统计人员编写了许多软件包。但是，此过程在Julia中也很容易做到。区别在于，Julia一路走来很快，您不必使用另一种语言来提高性能（更“严肃”的R包是用C之类的语言编写的）。R的问题在于，用R编写的包太慢而无法处理大量数据。唯一的选择是将软件包翻译成另一种语言，从而使R中的开发过程比Julia慢。

我对使用不同架构实现更快的速度和更容易的并行化的承诺感到感兴趣。因此，我一定会注意Julia的开发，但是直到它能够处理广义的线性混合模型，具有良好的通用引导程序包，用于构建设计矩阵的简单模型语言，等效于ggplot2的能力以及广泛的应用范围之后，我才会使用它。来自机器学习算法。

没有统计学家对工具的选择抱有原教旨主义的态度。我们将尽一切可能使我们最有效地完成工作。我的猜测是我会坚持使用R几年了，但是很高兴得到惊喜。

R中NA的豪华并非没有性能损失。如果Julia支持的NA的性能损失较小，那么这对于stats社区的一部分来说就变得很有趣，但是NA与R一起使用编译后的代码时，NA还会带来很多额外的工作。

R中的许多软件包都依赖于用传统语言（C，Fortran或C ++）编写的例程。在某些情况下，已编译的例程是在R之外开发的，后来用作R库软件包的基础。在其他程序中，例程首先在R中实现，然后在发现缺乏性能时将关键段翻译为编译语言。如果可用于实现等效例程的Julia将会很有吸引力。有机会对NA进行低级别支持，这将有一个机会，它可以简化将NA与已编译代码一起使用时对NA的处理。

大量的R库代表着许多用户的努力。这是可能的，因为R提供了原本无法提供/无法承受的功能。如果茱莉亚要被广泛使用，它需要一群用户，他们发现它比其他替代品要好得多，这值得提供非常基本的东西（例如，图形，日期类，NA等）。 ）（可从现有语言中获取）。

我会很前卫，没有R的经验，但是我和很多人一起工作，认为R是统计分析的出色工具。我的背景是数据仓库，由于Julia易于分发，但是标准编程模型比较多，所以我认为它可以很好地替代传统ETL工具的转换部分，而传统ETL工具的转换部分做得很差，大多数都无法轻松创建标准化转换，或重新使用已在先前数据集上执行的转换结果。如果我要构建一个OLAP多维数据集，而该OLAP多维数据集基本上需要从已经计算出的元组中构建更详细的元组（事实表），则对严格定义和类型化元组的支持就显得格外重要，今天的ETL工具没有“构建基块”可言。能够帮助，过去，该行业已通过各种方法解决了此问题，但仍需要权衡取舍。传统编程语言可以通过提供集中定义的转换来提供帮助，Julia可以潜在地简化更复杂的数据仓库系统中常见的非标准聚合和分布。

您也可以同时使用Julia和R。有Julia-to-R接口。使用此软件包，只要有需要的库，就可以在调用R的同时使用Julia来玩。

毫无疑问，Julia很有可能成为统计学家，让超级用户梦想成真，例如以SAS为例，它的强大之处在于用C语言编写的众多proc-Julia所能做的就是为您提供带有源代码的proc，矩阵为内置数据类型的SAS / iml。我毫不怀疑统计人员一旦掌握了这只小狗的功能，便会蜂拥而至。

哦，是的，朱莉娅很快就会超越R。主要原因是“宏”，其中95％的语言是在Julia中实现的，并且其无噪音，简约的语法。如果您没有使用Lisp类型的语言的经验，您可能还不了解它，但是您会很快看到R公式接口将如何成为过时和丑陋的机制，并被类似于CL的专用建模微语言取代循环宏。访问对象的低级引用也是一个很大的好处。我认为R仍然没有意识到，向用户隐藏内部结构实际上使事情变得复杂而不是简化。

正如我现在所看到的（在R后面大量使用R，并且刚读完Julia手册），Julia在R方面的主要缺点是不支持结构继承（这是有意的）。Julia的类型系统没有S4雄心勃勃；它也支持多重调度和多重继承，但是有一个陷阱-只有一个级别的具体类。另一方面，我很少看到R中的类层次结构超过3个级别。

时间会证明一切，但是会比大多数R用户想象的要早：）

Julia的第一个目标用例是数值问题。基本上，您可以将这些分析和计算科学领域分为数据科学（数据驱动）和模拟科学（模型驱动）。Julia首先处理仿真科学用例。他们还在处理数据科学案例，但速度较慢。R永远不会对模拟科学非常有用，但是Julia将会在两年内非常有用。

它需要能够将任何函数应用于对用户而言透明地不适合存储的大型数据集。
这至少包括在适合磁盘但不适合内存的数据集中运行的混合效果模型，生存模型或MCMC。并尽可能在分布在多台计算机上的数据集上。