我最近发现了FP bug(试图学习Haskell),到目前为止我已经看到了(一流的功能,懒惰的评估和所有其他好东西).我还不是专家,但是我已经开始发现在功能上比在基本算法上强制推理更容易(而且我很难回到我必须去的地方).
然而,当前FP看起来平坦的一个领域是GUI编程.Haskell方法似乎只是包装命令式GUI工具包(例如GTK +或wxWidgets)并使用"do"块来模拟命令式样式.我没有使用过F#,但我的理解是它使用OOP和.NET类做了类似的事情.显然,有一个很好的理由 - 当前的GUI编程完全是关于IO和副作用的,所以对于大多数当前的框架来说,纯函数式编程是不可能的.
我的问题是,是否可以使用GUI编程的功能方法？我无法想象在实践中这会是什么样子.有没有人知道任何尝试此类事物的框架(实验或其他)(或者甚至是为功能语言设计的任何框架)？或者只是使用混合方法的解决方案,其中OOP用于GUI部件,FP用于逻辑？(我只是想出于好奇心 - 我很想认为FP是"未来",但GUI编程似乎是一个非常大的漏洞.)
很多时候我听说F#不适合特定的任务,比如UI."使用正确的工具"是一个常见的短语.
除了缺少WinForms/WPF/ORM设计器等工具之外,我不确定F#究竟缺少什么 - 老实说!然而,特别是在UI方面,我被告知C#做得更好.那么,在强制使用F#时,F#的实际差异和遗漏是什么？
这是我提出的列表:
大量缺少工具支持
F#仍然是测试版
你的开发人员不知道F#
Mutables需要"可变"或需要ref,ref需要!解除引用
Mutables赋值< - 和ref使用:=(它们都是1个字符而不仅仅是=)
val需要DefaultValueAttribute来获取默认值
F#不会发出隐式接口
受保护的成员更难以处理
没有自动属性
抽象类上实现的虚拟成员需要两个定义
引用到LINQ-Expression-Trees会产生与C#/ VB略有不同的树(对于期望以特定格式表达其表达式的API而言很烦人)
没有stackalloc
F#没有？:条件运算符
F#中的指针可能被认为更麻烦
代表/事件有可能会被认为是比较烦琐(我认为他们是更容易,但至少它们是不同的)
没有自动类型转换(比如int to float或者隐式转换)
Nullable没有特殊的语法支持(C#的？类型注释和??运算符,以及在nullables上使用运算符.)
没有自动向上扩展到普通基类或装箱(例如:让x:obj =如果为真,那么其他为"hi"//这不会是类型检查)
没有警告就不能丢弃值("忽略"以解决它)
没有C风格的语法:)
问题:哪些是编写命令式或OO代码的障碍？为什么(简短的例子)？我错过了哪些？什么是最好的解决方法,为什么他们还不够？
请注意,我不是在谈论编写所谓的惯用F#,我当然不是在谈论函数式编程.我更感兴趣的是"如果我强迫自己在F#中编写UI或命令式/ OO代码,使用F#OO /命令式功能和类类型,会有什么最大的伤害？"
奖金 如果您不了解F#但使用C#或VB.NET并认为它是某种情况下更好的工具,请指出您觉得有吸引力的特定语言功能和语法.