F#在哪些领域"绝对没有意义"？

Question

Don Syme在他的SPLASH演讲中表示,F#并不打算成为C#的替代品,尽管它具有一般功能.他继续说F#在使用方面没有任何意义,但没有扩展到论文.

Answer 1

我认为将C语言替换为富有和成熟的语言会非常昂贵.因此,例如,目前,如果使用Visual Studio WinForms设计器可以为您提供优势,C#绝对是WinForms开发的最佳选择:F#没有WinForms设计器.

C#目前还支持更好的LINQ-to-SQL.我相信这些方面还有很多其他的例子.

然后需要整个C#技术人员将他们的技能更新为F#,同时保留C#技能以维护应用程序,同样昂贵.

最后,C#是一个有很多强大功能的优秀语言,一些F#甚至没有如CO /禁忌变异泛型和出针对DLR的动态规划(F#只是有一个未实现的操作)的内置支持.

因此,不期望F#取代C#,F#可以以新的方式发展,而不是花费所有的时间在已经很好覆盖的区域内追赶.

我认为最后一部分是一个非常好的观点.这是一篇写得很好的文章.奖励! (11认同)
感谢大家的亲切言辞和慷慨的赞成.顺便说一下,我想表达一下,我个人认为F#在很多很多领域(选项类型,不变性,尾调用优化,嵌套函数,异步,代码报价,模式匹配,活动模式)比C#更有效率和满意度,序列表达式,自定义计算表达式,Hindley-Milner类型推理,结构类型,结构比较,一流元组,......)并且希望看到该语言的广泛采用. (8认同)

Answer 2

这是一个棘手的问题,因为它不是很合格.您是在谈论一般语言,还是在谈论语言以及当前的IDE支持？或者你在谈论使用F#给出可用的库？

语言一般 - 我不认为有些地方使用F#绝对是胡说八道.对于完全托管的OS(例如Singularity)进行系统编程会很棒,我认为功能程序更容易正式验证(这对操作系统来说可能是个大问题).对于低级嵌入式系统,您可以使用元编程和面向语言的设施(例如,模拟硬件中的信号流等)
当前IDE的语言 - 当前的F#IDE有一些限制 - 它不适用于WinForms设计器(但它适用于Blend和WPF).
给予开发人员教育的语言 - 雇用F#程序员比雇用C#程序员更难.如果您正在创建一些没有任何复杂核心的应用程序(例如通常的"数据库接口"),那么在C#中开发它会更便宜(如果您可以聘请优秀的F#开发人员,他们可能会更快地完成它并且更少错误,但它可能不值得花费).
给定库提供的语言 - 如果您想限制自己使用F#只使用适合它的库,那么域会缩小一点.例如,LINQ to SQL和ASP.NET MVC可以与F#一起使用,但它并不完美.但是,对于许多项目来说,开发自己的库是有意义的,然后F#就成了很好的语言.

FWIW,我最近和一些数据库专家交谈过(这不是我的职责)他们都说LINQ to SQL糟透了,不管怎么说都不应该使用. (6认同)
另外,我想回应一下Tomas在这里所说的关于F#和WPF的内容.多年来我一直在用F#开发商业WPF应用程序,发现它确实运行良好.我最近在伦敦遇到了一个由十几个人组成的团队,他们使用大量的F#开发了更复杂的LOB WPF GUI并且喜欢它.出于某种原因,很多人都说F#和GUI不混合,但他们错了. (4认同)
@Jon - FWIW,过去一个月左右我一直在使用LINQ to SQL,这真是一种乐趣.在过去,我使用原始ADO,原始ADO.NET,原始JDBC,Grails/Hibernate,iBatis和自定义ORM.我会在任何一天选择LINQ to SQL.它非常优雅,在设计器表面上拖放表格,并且对生成的对象映射编写静态检查的C#LINQ查询,这对于使用原始SQL或像Hibernate这样的怪物来说是一种简单的乐趣.这是一个真正的生产力提升.我想知道这些数据库大师会提出什么选择 (3认同)

Answer 3

好问题.我会说开发人员,经理和客户都有零语言原因和许多不幸的技能,能力和态度原因.

Answer 4

许多Microsoft的UI技术(如WPF)都对数据绑定提供了出色的支持.当用户与UI交互时,有效数据绑定使用双向绑定来更新底层对象.这意味着有效的数据绑定需要可变对象.

F#强调不可变类型,与这种类型的数据绑定模型相比很差.虽然可以在F#中创建可变类型,但这样做会从语言中消除很多好处.使用可变性更自然的语言(例如C#)更有意义.

-1:由于没有任何具体的例子,我只是不买这个.我在使用WPF在F#中开发商业GUI应用程序时没有遇到任何此类问题,而关于可变数据结构的声明的明显反例是F#具有可变数组文字的语法(`[| 1; 2; 3 |]` )和C#没有! (7认同)
我认为这属于优秀F#libraries_的类别_lack.F#强调概念层面的不变性,但您可以使用不变性作为实现技术.我可以想象一个功能完善的声明性库,用于指定以函数/不可变方式使用的双向数据绑定,但是在封面下做所有讨厌的可变WPF内容(想象一下像`Event.map`和`Event. merge`或Rx Framework以一些聪明的方式扩展以编写双向计算). (3认同)

Answer 5

您可能需要考虑将其用于操作系统内核开发或低级嵌入式系统:-)

更进一步,我认为功能性创意比程序性或OO创意更能转化为硬件设计. (3认同)
@harpo - 我认为的一点是,除了使用过程语言或OO语言有益之外,没有什么能阻止函数式语言与硬件交互. (2认同)
@paxdiablo - 我在自定义硬件上需要的C w/asm块(HC12/16,ARM,RabbitCore,i386EX)上完成了不少系统,除了RabbitCore(64k,没有链接器),很多我的实现可以更清晰地使用功能样式.我认为C选择是开发人员惯性和经验的问题. (2认同)
@Ritch:虽然功能思想可能适用于(并行)逻辑电路的设计,但这与硬件 - 软件接口的良好运行并不相同.大多数外围设备都是高度有状态的,你需要一种顺序的方法来处理它们,它们比功能性语言更好地映射到命令式语言.OTOH F#不是纯粹的功能语言. (2认同)

Answer 6

如果您愿意放弃特定于C#的工具,并且支付适用的任何采用成本,则没有特定的区域F#至少不如C#那样有能力.