我想知道我是否应该继续学习OCaml或切换到F#或Haskell.
以下是我最感兴趣的标准:
长寿
哪种语言会持续更长时间？我不想学习用户和开发人员可能在几年内放弃的东西.
从长远来看,格里斯科大学的Inria,微软是否会继续支持他们各自的编译器？
实际性
像这样的文章让我害怕使用Haskell.哈希表是快速检索的最佳结构.Haskell支持者建议使用Data.Map这是一个二叉树.
除非好处很大,否则我不喜欢被绑在庞大的.NET框架上.
我希望能够开发的不仅仅是解析器和数学程序.
精心设计
我喜欢我的语言一致.
请通过逻辑论证和文章引用来支持您的观点.谢谢.
长寿
Haskell 事实上是功能编程研究的主要语言.Haskell 98将以稳定的形式存在多年,而Haskell可能持续10到30年 - 尽管语言将继续发展.社区对Haskell进行了大量投资,即使主要的GHC开发人员明天被一辆公共汽车撞到(着名的"剑桥巴士错误"问题),也有很多其他人可以加入这个行列.还有其他不那么复杂的编译器.
Caml由法国国家实验室INRIA的一个小组控制.他们也有很大的投入,其他人也投资了Caml,而且代码是开源的,而且编译器也不是太复杂,因此也会保持很长时间.我预测Caml将比Haskell稳定得多,因为INRIA人们似乎不再将其用作探索新语言思想的载体(或者至少他们这样做的速度比过去低).
谁知道公司会做什么？如果F#成功,微软可以支持它20年.如果不成功,他们可以在2012年拔掉插头.我无法猜测,也不会尝试.
实际性
哈希表是快速检索的最佳结构.Haskell支持者建议使用Data.Map这是一个二叉树.
这取决于你在搜索什么.当您的密钥是字符串时,三元搜索树通常比哈希表更快.当你的密钥是整数时,Okasaki和Gill的二进制Patricia树与散列竞争.如果你真的想,你可以使用IO monad在Haskell中构建一个哈希表,但是很少需要.
我认为懒惰评估总会有性能损失.但"实用"与"尽可能快"并不相同.以下是关于性能的:
最简单的方法是预测Caml程序的时间和空间行为.
F#位于中间(谁真的知道.NET和JIT会做什么？).
最难预测Haskell程序的时间和空间行为.
Haskell拥有最好的分析工具,从长远来看,这是产生最佳性能的因素.
我希望能够开发的不仅仅是解析器和数学程序.
对于什么Haskell的可能范围内的想法,检查出xmonad窗口管理器和繁多ofpackages的hackage.haskell.org.
除非好处很大,否则我不喜欢被绑在庞大的.NET框架上.
我无法评论:
精心设计
我喜欢我的语言一致.
评估一致性的一些要点:
Haskell的具体语法设计得非常好; 我对Haskell委员会所做的出色工作给我留下了深刻的印象.OCaml语法没问题,但比较受到影响.F#从Caml核心语法开始,有许多相似之处.
Haskell和OCaml都有关于运算符重载的非常一致的故事.Haskell拥有一个可以扩展自己的一致且强大的机制.OCaml没有任何超载.
OCaml有最简单的类型系统,特别是如果你不写对象和仿函数(很多Caml程序员都没有,尽管如果你写ML的话我不会写编写仿函数).Haskell的类型系统雄心勃勃且功能强大,但它不断得到改进,这意味着历史可能存在一些不一致性.F#主要使用.NET类型系统,加上类似ML的Hindley-Milner多态性(请参阅问题"什么是Hindley-Milner".)
OCaml在是否认为变体应该是静态类型或动态类型方面并不完全一致,因此它提供了两者("代数数据类型"和"多态变体").由此产生的语言具有很强的表达能力,这对专家来说非常好,但对于业余爱好者而言,使用哪种结构并不总是显而易见的.
OCaml的评估顺序是官方未定义的,这在具有副作用的语言中是一种糟糕的设计选择.更糟糕的是,实现是不一致的:字节编码的虚拟机使用一个订单而本机代码编译器使用另一个订单.
如果你了解OCaml,你应该学习F#还是Haskell？
我相信答案肯定是肯定的,理想情况下你应该学习所有三种语言,因为每一种语言都可以提供,但F#是唯一一个有重要未来的语言,所以,如果你只能切实学习一种语言,那么通过阅读我的Visual F#来学习F# 2010年技术计算书或订阅我们的F#.NET期刊.
长寿
微软承诺在4月份将其作为Visual Studio 2010的一部分发布时支持F#.所以F#至少在几年内保证了美好的未来.随着像一个高性能的本地代码REPL实际上,重要的功能的强大组合,高级别内置到.NET 4和生产质量IDE模式并行构建,F#是一个长期领先于其他所有功能的编程方式语言现在适用于现实世界.坦率地说,在不久的将来,没有人会做任何可能与F#竞争的事情.我自己的开源HLVM项目试图这样做,但还远未准备好.
相比之下,OCaml和Haskell都在极其无效的方向发展.这已经杀了OCaml好几年了,我希望Haskell能够在接下来的几年内效仿.大多数前职业OCaml和Haskell程序员已经转移到F#(例如瑞士信贷,飞蛙咨询公司),其余大部分人无疑将在不久的将来转向更实用的替代品,如Clojure和Scala.
具体来说,OCaml的QPL许可证可以防止其他任何人修复其越来越多的基本设计缺陷(32位机器上的16Mb字符串和数组限制,没有共享内存并行性,没有值类型,通过类型擦除的参数多态,解释REPL,繁琐的FFI因为他们必须只以补丁的形式将衍生作品分发到原版,而Debian软件包维护者拒绝承认替代上游.添加到语言中的新功能,例如OCaml 3.12中的一流模块,远不如多核功能那样有价值.
一些项目是为了拯救OCaml而开始的,但事实证明它们太晚了.该并行GC实际上是无用的,大卫·泰勒退出电池包括项目(尽管它已被拾起,并在切下的形式发布).因此,OCaml已经从2007年最受欢迎的功能语言变为今天的严重下降,自2007年以来,其数量下降超过50%.
Haskell的工业用户数量少于OCaml,尽管它确实具有多核支持,但它仍然在非常低效的方向上开发.Haskell几乎完全由剑桥(英国)的微软研究院的两个人开发.尽管纯粹的函数式编程对于性能设计不利,但他们仍在继续尝试开发针对多核的并行Haskell解决方案,因为大量不必要的复制会导致内存存在,并破坏任何可扩展并行性的希望.多核.
Haskell在业界唯一的主要用户是Galois,拥有大约30名全职Haskell程序员.我怀疑他们会让哈斯克尔彻底死去,但这并不意味着他们会把它发展成一种更普遍有用的语言.
实际性
我写了你引用的关于哈希表的文章.它们是一个很好的数据结构.其他人提到了纯粹的功能性替代品,如三元树和帕特里夏树,但这些通常比哈希表慢〜10倍.原因很简单,缓存未命中占据了今天的性能问题,并且树会产生额外的O(log n)指针间接.
我个人的偏好是可选的懒惰和可选的纯度,因为两者在现实世界中通常都是反效果的(例如,懒惰使得性能和内存消耗极不可预测,并且纯度严重降低了平均情况性能并使互操作性成为噩梦).我是唯一一个通过我自己的公司完全靠函数式编程谋生的人之一.我只想说,如果我认为Haskell是可行的,我会在几年前实现多样化,但我一直选择不这样做,因为我不相信它具有商业可行性.
你说"我不喜欢被绑在一个庞大的.NET框架上,除非它的好处很大".好处是巨大的.您将获得一个生产质量的IDE,一个生产质量的JIT编译器,可以执行非常有效的优化,如类型专用泛型,生产质量库,用于从GUI编程(参见32行F#中的生命游戏)到数字运算的所有内容.但至少对我来说,.NET的真正好处是你可以卖掉你用F#写的图书馆并赚很多钱.没有人成功向OCaml和Haskell程序员销售库(我是为数不多的人之一),但F#库已经大量销售.因此,如果您想通过编写软件来谋生,那么庞大的.NET框架非常值得.
精心设计
这些语言都设计得很好,但用途不同.OCaml专为编写定理证明而设计,Haskell专门用于研究Haskell.F#旨在解决OCaml和Haskell的所有最严重的实际问题,例如互操作性差,缺乏并发垃圾收集以及缺乏成熟的现代库(如WPF),以便为大量受众提供高效的现代语言.
这不是您的标准之一,但您是否考虑过工作空缺？Haskell目前确实列出了144个职位,Ocaml list 12和C#list 26,000.这些数字并不完美,但我敢打赌,一旦F#出货,不久之后它就会超过Haskell和Ocaml的工作列表数量.
到目前为止,Visual Studios中包含的每种编程语言都有数以千计的工作列表.在我看来,如果你想要最好的机会使用函数式编程语言作为你的日常工作,那么F#很快就会成功.
长寿
没人能预测未来,但是
OCaml和Haskell多年来一直表现良好,这预示着他们的未来
当F#与VS2010一起发布时,MS将有法律义务支持它至少5年
实际性
Perf:我没有足够的Haskell第一手经验,但基于二手和三手信息,我认为OCaml或F#更实用,从某种意义上说,我认为你不太可能在Haskell中获得与在F#的OCaml中执行的相同的运行时性能.
库:轻松访问.Net Framework是F#的一大优势.如果你愿意的话,你可以把它视为"与这个笨重的东西联系在一起",但不要忘记"你可以访问一个庞大的庞大的库,通常是非常有用的东西".与.Net的"连接"是F#的一大卖点.F#更年轻,第三方库也更少,但除了.Net上的"盒子里的" 库外,还有例如FsCheck,FParsec,Fake和其他一些库.
工具:我没有足够的个人经验来比较,但我认为VS与F#的集成优于今天你会发现的OCaml/Haskell(并且F#将在明年继续改进).
更改:F#在接近VS2010中的第一个受支持版本时仍在变化,因此在不久的将来您可能不得不忍受语言/库的一些重大更改.
精心设计
Haskell绝对是美丽和一致的.我不太了解OCaml,但我的预感是同样有吸引力.我认为F#比其中任何一个都"更大",这意味着更多的灰尘角落和不一致(主要是由于调解FP和.Net之间的阻抗不匹配),但整体F#对我来说仍然感觉"干净",并且确实存在的不一致性至少是有充分理由/意图的.
总体
在我看来,你会很好地了解这三种语言中的任何一种.如果你知道一个你想要用它的大型长期项目,可能会脱颖而出,但我认为很多技能都可以转移(在F#和OCaml之间比从Haskell更容易转移,但在任何这些三个比用Java说的那样.
这个问题没有简单的答案,但这里有一些事情需要考虑:
Haskell和OCaml都是成熟的语言,具有强大的实现.实际上,Haskell有很多很好的实现,但我不认为这对你的目的有利.
F#更年轻,谁可以预测微软将决定采取哪些措施？您对此的感受更多地取决于您对Microsoft的看法,而不是任何人可以告诉您的编程语言.
OCaml(或一般的ML)是一种很好的实用语言选择,支持做很酷的功能性而不会让你以一种可能不舒服的方式工作.您可以充分利用代数数据类型,模式匹配,类型推断以及其他所有人喜欢的东西.哦,和物体.
Haskell为您提供了所有这些(除了对象之外),但也或多或少地强迫您重新思考您认为编程的所有知识.这可能是一件非常好的事情,如果你想要学习一些新的东西,但它可能比你想要的更多.我说这是一个只有在成为一个高效,快乐的Haskell程序员的道路上的人.
OCaml和Haskell都被用来编写许多不同类型的程序,而不仅仅是编译器和AI或其他任何程序.谷歌是你的朋友.
最后一点:OCaml为您提供了散列表,但如果您真的想要接受函数式编程,那么在代码中使用它是不明智的.持久树(如Data.Map)确实是Haskell的正确解决方案,并且具有许多不错的属性,这是您在选择Haskell时要学习的很酷的事情之一.
京公网安备 11010802040832号 | 京ICP备19059560号-6 