最新评论

好东西，很实用！

额。。。。先前我写过了，不过实际运用中还没有用

呃,好像我的文章只是借用了python中decorator的思想,其实和python一点关系都没有. 从核心实现来看,本文是调用了python的decorator实现,而我的文章中描述的是[b]在c#中实现了类似python中decorator的语法[/b],两者是完全不同的.

@Jeffrey Zhao 嗯，只是感觉这个python module还不错

F#毕竟是函数式编程语言，用类C的语言去衡量其可读性是不可取滴。

@极品菜鸟 主要就是介绍下这个module啊

请问：你想说什么？

@地狱门神 嗯，可读性更好一些。 我习惯用括号了...

其实这么写就行了 [code=csharp] let f = fun () -> printf "hello" printfn "world" let makewithdraw (balance:int) = let refb = ref balance fun amount -> if !refb >= amount then refb := !refb-amount !refb else failwith "Insufficient funds" [/code]

用这种方法解压有密码保护的zip压缩包时能不能不弹出密码输入窗口

函数是一等公民，这个也应该谈谈吧？

@Jeffrey Zhao 呵呵，简历上啥东西最不可信，我最不信的就是精通啥啥啥

@Ivony... 谢谢指教，不过有些专用名词我不喜欢翻译过来，尤其是专有名词。。。

我是精分函数式编成 "精分"=>"精神分裂"

精通函数式编程……

看别人用另一种语言和另一个视点来写同一个东西还真是有意思。

Higher-Order function 就叫做高阶函数吧，虽然中文翻译不统一（泛函、算子）问题是英文也是怪怪的。 Currying Fuction：柯理化函数

@cokkiy 慢慢习惯了就好了，C#不也变的越来越不直观了

其他语言看习惯了,看这种function类型的语言，好费经啊

[quote]Jeffrey Zhao：我也打算写一个简单的F# by Example系列了。[/quote] 我准备写个小系列，介绍下F#的一些有特色的东东

@Jeffrey Zhao 期待你的大作 对的，用比懂更难一些。希望我说了函数后能让大部人先能看懂F#的函数（当然你除外啦，你己经很懂了，呵呵，要不然又要说我当别人是小白了）

@Anders Cui 谢谢

对了，话说我至今觉得F#有些难懂难用，部分特性很难懂很难用。 或者说，把F#代码直接不假思索的读，可以看懂这些意思，但是如果你要写出API来就不容易了。 嗯，那么更确切的应该说是，懂比用容易——啊，但我也没说懂就容易了……。

我也打算写一个简单的F# by Example系列了。

很不错，赞!

@rex xiang 老兄写得相当不错，现在为何不写点F#的东东呢？

[quote]Anders Cui： @芭蕉 这个例子看来不适合作为学习F#的快速入门:) 该筛法有个很重要的特点就是递归有个上限sqrt(n)，代码没有反映出来。 以前我曾写过一篇关于这个筛子的文章，我的写法几乎还是按命令式语言的风格来写的，但是在评论里面有个朋友给出了非常好的代码，我觉得很好地体现了列表操作和递归的特点： [code=csharp] let sqrt_int x = x |> float |> sqrt |> int let find_prime max = let rec filter prime numbers = match numbers with ...[/quote] 咦?这不是我初学F#的时候(当然现在还是初学者)写的东西么?有人认可俺实在是太荣幸老...

@Anders Cui erlang没有如C#那样的容器，它是真的no side effect的，它的list也是F#的list形式，毕竟是函数式语言。不过拷贝是逃不掉的。 erlang的拷贝，据说是为了并发性和容错，但是我并没有理解这一点，因为如其他语言/平台，只是做到了immutable也已经够了，no sharing这一点过了。 这也是erlang虽然并发强，适合做网络程序，但是做不了计算密集型应用的原因，因为什么都是拷贝来拷贝去，比一个字长的引用拷贝费时多了。

@芭蕉 它不是copy on write，erlang中没有write只有bind（对一个变量bind以后再也不可变），它是任何传递都是copy，除非是很大的二进制对象才会传递引用。

[quote]Jeffrey Zhao： 对了，我刚才忽然意识到我犯了一个错误。 Erlang的性能问题不在于immutable（immutable理论上性能会有问题但是实际上基本上不成问题），而在于no sharing。 no sharing导致大量数据会拷来拷去，性能影响在这里。[/quote] 但是，immutable只是说某个值本身不能修改，在程序中值的修改是客观需要的。比如对列表来说，你对它添加或移除一个元素，值也是修改了啊，如果此时是你说的no sharing，性能就会有问题吧。

[quote]Jeffrey Zhao： 对了，我刚才忽然意识到我犯了一个错误。 Erlang的性能问题不在于immutable（immutable理论上性能会有问题但是实际上基本上不成问题），而在于no sharing。 no sharing导致大量数据会拷来拷去，性能影响在这里。[/quote] 对Erlang不熟，但如果按你说的，它是按copy on write pattern实现的immutable的话，那拷来拷去确实很影响性能

对了，我刚才忽然意识到我犯了一个错误。 Erlang的性能问题不在于immutable（immutable理论上性能会有问题但是实际上基本上不成问题），而在于no sharing。 no sharing导致大量数据会拷来拷去，性能影响在这里。

@芭蕉 我可没有说过immuable意味着性能差，我也同意immutable如果操作适当，性能的确不会差。 但是erlang是“必须、完全immutable”，也就是说它由不得程序员，所以有些时候性能势必会差一些。 // 我喜欢争论，多多包涵，呵呵。

我真不想争论这个东西，前面说过了，这个争论真的很激烈，各有各有好处。但如果认为immutable就意味着性能差，那我也强烈不认同，immutable类型，如果操作适当，性能并不一定会差。

@芭蕉 C#里的基本类型本就是immutable的，int, long, double, datetime哪个不是immutable的？struct的copy特性，本来就非常倾向于immutable，这是语言/平台设计决定的。 其实C#和F#都是把immutable与否交给了程序员，两者是一样的，F#并不占优势。 至于你说C#如果放在现在设计……我认为如果还是和如今C#语言一样的目的，那么必然是mutable的，何况F#都是可以mutable的。 因为如何设计和“年份”无关，只和作用有关。immutable并行、FP的产物，我这里举一些流行语言的例子： F#是FP，新语言，immutable，可mutable。 C#不是FP，旧语言，mutable。 Erlang，for parallel，很旧的语言了，immutable。 Axum，新语言，mutable。 Java平台上的Groovy和Scala，新语言，mutable。 值得一提的是Axum和Scala，前者专为并行设计，后者的Actor模型是一大特色，几乎也可以说是for parallel的语言，但它们也都是mutable的，或者说，他们把灵活性留给了程序员。 所以你说“如果C#放到现在就mutable”的说法，我找不到事实根据和理论基础，我不同意。 在并行世界里，我也不接受完全immutable，因为很多时候程序员需要灵活性，明白自己什么时候可以用mutable的，immutable丧失共享内存的便利（和性能），也不一定被看好。 例如如今Erlang界，讨论的很凶的东西之一就是Erlang Style Programming（一种编程风格，而并不一定是Erlang本身），Erlang有一个很死板的特点就是完全immutable，统统拷贝，有损性能。

我觉得，一门语言，优缺点对比，比较重要。即使优点很多，如果有些缺点，让某些人或某些业务，不能接受，那么也不适合这个人来开发。开发本来就是技术活，再加上代价，权衡利弊，就没有开发的必要了。为了学习而学习，是学生年代的事了。很多人过了那个阶段

@Anders Cui 嗯，我只是为了通过例子说明一些F#的基本语法，并没有考虑该算法的最优实现。 而且我写的里面用到了If ... else, 按照functional programming style的观点，是不应该用这个的，应该用Pattern Matching 你贴的实现比较能反映函数式编程的style，不过我不大喜欢使用@来联接两个List,这个一般来说在性能上要比在List前面插入一个新元素差的多，尤其是前面的List比较大时

[quote]Jeffrey Zhao： @芭蕉 不要“默认”持反对意见的人是小白比较好吧，这里也有几个搞F#的人了，而且我是提出质疑和自己的看法，没有反对你的观点。 我不是F#和函数式编程的初学者，我甚至算是有点“专注于并行计算”的吧。对于F#对并行计算，我在生产环境下都在用。 我的意思是，我也知道F#的优势，但是我并不觉得F#和函数式编程有你说得那么好，或者说那么“自然而然”地就说好就好了。 就比如，像数学公式一样表达自己思想，难道就是“专注”了吗？这是需要跟进一步解释的。还有，为什么说函数式编程像“数学公式一样”也是个没有解释清楚的东西。 至于生产力问题，我始终认为F#是一门难学难用的语言，很难像C#一样成为大众型语言。 还有immutable，F#和C#的区别只是默认情况下是不是immutable的。F#在并行计算上的优势，一个重要的方面是async workflow，但我认为不是immutable。 因为F#也可以做到mutable，C#也可以写成immutable（不改不就行了，呵呵），immutable的确对并行计算有优势，但是并不是F#带来的——一个默认特性而已。[/quote] 没默认谁是小白，至于F#,也并不是要来取代C#的，各有各的长处吧，比如说在金融，数学计算方面F#确实有它的长处，但如果是用F#去搞GDI开发，我想也没几个人愿意去搞吧。 至于immutable和mutable的问题，这个本来争论就很激烈，有很多人甚至极端的认为mutable是邪恶的，总的来说现在是immutable比较占优势吧，我相信如果C#是现在也设计出来的，它的基本类型也应该全是immutable的。

函数式语言与我们大部分程序员日常接触的语言是完全不同的东西,如果你喜欢,可以去学习,不喜欢,就不用管它,没必要说些无聊的话

@芭蕉 这个例子看来不适合作为学习F#的快速入门:) 该筛法有个很重要的特点就是递归有个上限sqrt(n)，代码没有反映出来。 以前我曾写过一篇关于这个筛子的文章，我的写法几乎还是按命令式语言的风格来写的，但是在评论里面有个朋友给出了非常好的代码，我觉得很好地体现了列表操作和递归的特点： [code=csharp] let sqrt_int x = x |> float |> sqrt |> int let find_prime max = let rec filter prime numbers = match numbers with | [] -> prime | head::_ when head = 1 -> filter [] numbers.Tail | head::_ when head > (sqrt_int max) -> prime @ numbers | _ -> numbers.Tail |> List.filter (fun i -> (i % numbers.Head) > 0) |> filter (prime @ [numbers.Head]) filter [] [1..max] 120 |> find_prime |> printfn "%A" [/code]

[quote]♂风车车.Net： 虽然,F#出现已经有那么久. 但是似乎目前并没有 利用F#写的出来东西出现. 也许我孤陋寡闻吧! 所以,F#到底如何?不清楚!也许以后在某个方面作为比较大. 估计在我当程序员的这些年里,是看不到它的作为![/quote] F#的不少特性是很值得提倡的，只是有些难以掌握，不过学一个语言重要的是学它的思想。例如workflow，例如比C#还要完整的code as data。 F# web toolkit便是基于后者，可以写F#代码，直接得到JS代码，异步AJAX等等，统统在一起了 至于前者，你可以看看基于前者实现的async workflow：[url]http://www.infoq.com/presentations/Concurrent-Programming-with-Microsoft-F-Amanda-Laucher[/url]

@芭蕉 不要“默认”持反对意见的人是小白比较好吧，这里也有几个搞F#的人了，而且我是提出质疑和自己的看法，没有反对你的观点。 我不是F#和函数式编程的初学者，我甚至算是有点“专注于并行计算”的吧。对于F#对并行计算，我在生产环境下都在用。 我的意思是，我也知道F#的优势，但是我并不觉得F#和函数式编程有你说得那么好，或者说那么“自然而然”地就说好就好了。 就比如，像数学公式一样表达自己思想，难道就是“专注”了吗？这是需要跟进一步解释的。还有，为什么说函数式编程像“数学公式一样”也是个没有解释清楚的东西。 至于生产力问题，我始终认为F#是一门难学难用的语言，很难像C#一样成为大众型语言。 还有immutable，F#和C#的区别只是默认情况下是不是immutable的。F#在并行计算上的优势，一个重要的方面是async workflow，但我认为不是immutable。 因为F#也可以做到mutable，C#也可以写成immutable（不改不就行了，呵呵），immutable的确对并行计算有优势，但是并不是F#带来的——一个默认特性而已。

@jeff_sh 函数式语言己经和C语言是两个大家庭的东西了，相差当然很大

[quote]Jeffrey Zhao： immutable这个问题我的看法是，C#你可以写成immutable的（不去改不就可以了），F#也可以通过mutable关键字或ref的方式来mutable，所以这个好处有限。 函数式编程是否可以简化程序，专注算法实现我也不是很清楚，有没有更详细的解释？[/quote] 简化程序我主要指的是借助强大的type inference,我们可以少敲不少东西，这样不就变相提高生产率了？至少于专注算法实现，一门函数式语言，借助于high order functions,我们可以像在写数学公式一样表达自己的思想，难道这不算专注么？ 至于immutable的问题，等以后看到F#对并行计算的支持，你就明白了

虽然,F#出现已经有那么久. 但是似乎目前并没有 利用F#写的出来东西出现. 也许我孤陋寡闻吧! 所以,F#到底如何?不清楚!也许以后在某个方面作为比较大. 估计在我当程序员的这些年里,是看不到它的作为!

@PXDKK 无所谓跟风不跟风，我觉得学一门语言主要是学一种思想

[quote]PXDKK ： 微软的创新是无意义的!!! 我不跟风[/quote] 你还不咋了解，怎么就觉得无意义的呢？ 我觉得跟F#比跟一些Silverlight有价值的多呢。

[quote]芭蕉： 比如F#里面的基本类型基本上全是immutable的，可以很好的适用于并行计算， 比如F#有强大的类型推断机制，并且是一门函数式语言，这可以简化我们的程序，让我们专注于算法的实现。 再比如，F#是运行于CLR之上的，这意味着它可以使用丰富的.net库函数（当然这个只对.net程序员而言)[/quote] immutable这个问题我的看法是，C#你可以写成immutable的（不去改不就可以了），F#也可以通过mutable关键字或ref的方式来mutable，所以这个好处有限。 函数式编程是否可以简化程序，专注算法实现我也不是很清楚，有没有更详细的解释？

能不能先来个max()类型的简单的看看先？ 搞这么多-><-的

函数式语言.......,关注ing....