k******a
发帖数: 2436 | 1 来自主题: Programming版 - 关于FP I am baffled by these discussions. You guys need to spend a few minutes with
Lisp to understand what functional programming is. IO are both considered
immutable values and there is no assignment or concept of variables.
C# only introduced lambda as a language feature, which allows run-time
created function instances, not just compile-time. That makes functions
first class data types.
Did java added lambda? I have no knowledge of it. But without a language
level change you can at most get syntax ... 阅读全帖 |
|
E*****m
发帖数: 25615 | 2 来自主题: Programming版 - 关于FP
with
why IO is immutable? You get same input every time?
Lisp has "setq", which is indeed assignment. There is no such thing
in Haskell, if I got it right.
Actually, LISP is not the purest FP language. You should not use Lisp
as an FP benchmark. |
|
p*****2
发帖数: 21240 | 3
hard
it
能不能谈谈immutability？ |
|
|
p*****2
发帖数: 21240 | 5 FP里没有for，while这个我理解，因为要immutability。但是为什么python, ruby这种
语言也把for给阉割了呢？是因为学习FP语言的结果吗？ |
|
t***a
发帖数: 416 | 6 如果写多线程的东西，那纯fp结合actor的开发效率是要高很多的，即便是在我两三年
前初学的时候, 广泛使用immutable collection让bug少了非常多。可惜我就做过一两
个大量涉及多线程的项目，这方面体验不深。
对于一般程序，如果思路转变过的话，fp的优势在于易读，bug-free(只要想好，写出
来基本上就是对的)
尤其是实现算法的时候，你知道，好些算法的描述其实是更贴近fp的 |
|
p*****2
发帖数: 21240 | 7
check
我感觉你说的这两个例子，后者的优势更在immutability上。不知道对不对。 |
|
p*****2
发帖数: 21240 | 8
资源管理是个大问题。这个我一直没想明白。都是immutable的因此同一个数据结构需
要很多copy，最后把内存用尽了。 |
|
m********5
发帖数: 17667 | 9 Not necessarily. I believe it depends on programming style. If your style is
FP enough, your code will use >100 times smaller memory than non-FP code.
In extreme case, the FP can be used to handle infinite data with lazy
evaluation and referential transparency. Of course, one can also implement
similar thing in C++ with functors, but it is still FP, just approximated
with another language with a lot of pain in the ass.
Haskell performance and memory profile are really mediocre, it keeps copying
... 阅读全帖 |
|
t****a
发帖数: 1212 | 10 I don't really see the point of using functional programming languages for
real production projects, though clojure is very popular now.
好问题，但也许你尝试用FP语言做一做事情，亲身体验一下，会有不同的感觉。
my point is that in a few cases you do need to operate on functions, all
languages have such features: C has function pointers, java has anonymous
inner classes, python has lambda. it's just that they do not openly
advertise them as "functional".
FP和上述冯诺依曼机式语言有好些地方不一样。最主要之一是immutable的数据结构。
个人的体会是它使得写程序减少了变量，强迫程序员用类似数学推理的方式写... 阅读全帖 |
|
m*********t
发帖数: 527 | 11 其实你们应该多说说：什么样的问题用 FP 来解决很合适，和 OOP 比较呢？。内核以
及嵌入式？ 前端？ game？数据分析？复杂的并行和需要大量内存的科学计算？ 我看
到一些 haskell 的例子内存占用似乎比 C 要多好几倍（是不是 immutable 的原因？
），这样对于 memory bandwidth limit
的计算程序怎么弄？
还有说说这东西在大规模开发的时候代码可读性和可维护性？ |
|
t*****n
发帖数: 4908 | 12 这方面，采取 immutable 的数据结构也会更适合 modern CPU，比如 cache-friendly
（sharing, no read/write barrier），比如 SIMD ，比如 thread 间数据的交换，可
以尽量避免 CAS 等。就连 Garbage Collection 也可以针对 cache 进行优化，而不需
要修改应用层面的东西。Scientific Computing 很多时候追求高效，结果把 C 或者
Fortran 的源程序调得乱糟糟，事后很难维护，长远来看是得不偿失的。
真能码字。不过计算远没有你想的那么差。只有低水平的编程者，没有生来就乱的语言
。高手写的fortran，远胜入门者写的fp。
Haskell
) |
|
m*********t
发帖数: 527 | 13 What about memory bandwith limit if you use all pure immutable objects? e.g.
I have a parallel gpu program that read + write 200 GB/s on the GDDR5 RAM. |
|
m*********t
发帖数: 527 | 14 比如我有一个 float 数组(长度大约 10^8 to 10^9，占用几个 G 的内存)，然后我用
成千上万个 thread 来计算然后 update 数组里面元素的内容（为了保证 thread 不冲
突算法和 sync 都需要考虑）。而如果用 immutable 在这个情况怎么处理？
do
the
object |
|
t****a
发帖数: 1212 | 15 I don't really see the point of using functional programming languages for
real production projects, though clojure is very popular now.
好问题，但也许你尝试用FP语言做一做事情，亲身体验一下，会有不同的感觉。
my point is that in a few cases you do need to operate on functions, all
languages have such features: C has function pointers, java has anonymous
inner classes, python has lambda. it's just that they do not openly
advertise them as "functional".
FP和上述冯诺依曼机式语言有好些地方不一样。最主要之一是immutable的数据结构。
个人的体会是它使得写程序减少了变量，强迫程序员用类似数学推理的方式写... 阅读全帖 |
|
m*********t
发帖数: 527 | 16 其实你们应该多说说：什么样的问题用 FP 来解决很合适，和 OOP 比较呢？。内核以
及嵌入式？ 前端？ game？数据分析？复杂的并行和需要大量内存的科学计算？ 我看
到一些 haskell 的例子内存占用似乎比 C 要多好几倍（是不是 immutable 的原因？
），这样对于 memory bandwidth limit
的计算程序怎么弄？
还有说说这东西在大规模开发的时候代码可读性和可维护性？ |
|
t*****n
发帖数: 4908 | 17 这方面，采取 immutable 的数据结构也会更适合 modern CPU，比如 cache-friendly
（sharing, no read/write barrier），比如 SIMD ，比如 thread 间数据的交换，可
以尽量避免 CAS 等。就连 Garbage Collection 也可以针对 cache 进行优化，而不需
要修改应用层面的东西。Scientific Computing 很多时候追求高效，结果把 C 或者
Fortran 的源程序调得乱糟糟，事后很难维护，长远来看是得不偿失的。
真能码字。不过计算远没有你想的那么差。只有低水平的编程者，没有生来就乱的语言
。高手写的fortran，远胜入门者写的fp。
Haskell
) |
|
m*********t
发帖数: 527 | 18 What about memory bandwith limit if you use all pure immutable objects? e.g.
I have a parallel gpu program that read + write 200 GB/s on the GDDR5 RAM. |
|
m*********t
发帖数: 527 | 19 比如我有一个 float 数组(长度大约 10^8 to 10^9，占用几个 G 的内存)，然后我用
成千上万个 thread 来计算然后 update 数组里面元素的内容（为了保证 thread 不冲
突算法和 sync 都需要考虑）。而如果用 immutable 在这个情况怎么处理？
do
the
object |
|
g*****g
发帖数: 34805 | 20 While Java Future does have a lot of boiler plate codes, other frameworks
have simplified it quite a bit. Spring, for example, can use AOP to declare
a method asynchronous, all it takes is one annotation.
@Async
void myMethod()
Obviously you can have multiple Async tasks in one class. You can call other
Async tasks. You can pass parameters you want without constructing a task,
and you can get a Future
back if you
want. And one important nice thing compared to your approach is that it's
strongly... 阅读全帖 |
|
o**2
发帖数: 168 | 21 非常感谢你的反馈，我会逐一答复反馈中的三个方面：Spring @Async；Immutable
objects；和JMS等。
declare
other
task, |
|
X****r
发帖数: 3557 | 22 python的string是immutable的，所以在字符串后面不断加长就会不断分配新的字符串
。一般的做法是用个list，每次把新字符串放到list的最后，完了一个join。 |
|
d**o
发帖数: 864 | 23 If you want to copy an object, normally do a copy explicitly.
Cite from Stackoverflow:
"passing by value" and "passing by reference" are not concepts that are
relevant in Python. The relevant concepts are instead "mutable object" and "
immutable object". |
|
c****e
发帖数: 1453 | 24 I know immutable. But it's python's complier's job to optimize this.
javascript used to be slow to s+=, now it's even faster than stringbuidler
because people like to write in that way.
I agree the way he wrote is not every FP. where|join can make code more
expressive. But my point is even his code is verbose, as long as it works it
could be fine. I don't know your concrete story, but don't laugh at
novince. He might just need a little bit practice and learn a few
conventions.
Back to the post, ... 阅读全帖 |
|
l*****t
发帖数: 2019 | 25 这个有什么课可以上面，感觉有很想回学校问教授的想法。
以前在学校里学这些个东东的时候哪里有什么concurrent 不concurrent ，都是
immutable 没有mutable的。我在想是不是哪些个人的研究方向，应该有些课程或
seminar 什么的听听吧。
mutation |
|
c******o
发帖数: 1277 | 26 用了几个月scala. 说一下我的感觉
scala是一个general purpose language, 它有足够的工具解决绝大部分项目和问题。
scala不是一个all purpose language,它明显在很多领域只是可以用而已。大部分领域
有更好的语言了。
我的感觉是，scala最适用于：
1. 多并发，大规模的后端，很好的支持并发。
2. 分布式系统，高可用性，高容错，分布式实现容易。
3. 复杂逻辑后端，有很多很好的抽象方法可以选用，用的好，可以很干净。
4. 各种专业的库，是一个很好的建库的语言，当然，要求也高。
这些主要是因为：
1. FP和OO的融合使得scala有很强大的标准库支持，也很容易使人迷惑， 看看那个
play的Json library, 很强大，也很囧。
2. FP和OO的融合使得scala有很多种抽象的方法，很强大，但是也很容易被滥用，太多
pattern可以用来干同一件事。
3. 静态类型和type inference使得scala很适合大型，复杂的系统,高效的系统，也能
够写出比较简洁和干净的代码，要是不注意，容易影响可读性。
4. 调用jav... 阅读全帖 |
|
c******o
发帖数: 1277 | 27 据Martin说有些银行开始用了，但是不让宣扬。
要是不成，大概就要痿了。
本身就是大公司用才爽，小公司用起来有种屠龙的感觉，可以用，也好用，省时间，就
是好像也可以不用，尤其是你本身就用FP，immutability，future。 |
|
c******o
发帖数: 1277 | 28 哦，所以兼听则明么。
scala的FP/immutability/future 的async的用法是很不一样的。
看看很好。 |
|
b*******r
发帖数: 361 | 29 恩
好像purely functional是指immutable吧…这貌似是个趋势啊 |
|
b*******r
发帖数: 361 | 30 嗯。processes之间的independency貌似更符合大数据的需要。immutable是充分不必要
条件。 |
|
p*****2
发帖数: 21240 | 31
我觉得那个scala for impatient不错。对于java程序员来说要接受FP确实需要段时间
转变思维。主要是三点
1. immutability
2. function is first citizen
3. recursive, no iteration
感觉主要是第一点更需要时间去熟悉。所以scala来了一个混合型的。虽然可以让java
程序员过渡一下，但是也容易让人逻辑混乱。 |
|
c******o
发帖数: 1277 | 32 内部当然都是大同小异的，在一样的JVM上跑。
就是在编的时候会好model很多，都是immutable。
上面那个例子，我可以在很容易的组合任意多个future在yield里。
如果两个有关联，就直接吧前一个的结果放到后一个输入里，自然就会等待。
for (
a1 <- attack...
a2 <- hitByThunder(a1)
a3 <- die(a2)
a4 <- hitByWind()
) yield (combine (a3,a4))
主要是可读和可操作性好多了，你知道它是不变的，不可能会受其他future/thread的
影响。
还有，上面的结果也是future, 其实就是说,你还可以继续在其他地方拿它组合，完全
是对你透明的。 |
|
p*****2
发帖数: 21240 | 33
我觉得那个scala for impatient不错。对于java程序员来说要接受FP确实需要段时间
转变思维。主要是三点
1. immutability
2. function is first citizen
3. recursive, no iteration
感觉主要是第一点更需要时间去熟悉。所以scala来了一个混合型的。虽然可以让java
程序员过渡一下，但是也容易让人逻辑混乱。 |
|
c******o
发帖数: 1277 | 34 内部当然都是大同小异的，在一样的JVM上跑。
就是在编的时候会好model很多，都是immutable。
上面那个例子，我可以在很容易的组合任意多个future在yield里。
如果两个有关联，就直接吧前一个的结果放到后一个输入里，自然就会等待。
for (
a1 <- attack...
a2 <- hitByThunder(a1)
a3 <- die(a2)
a4 <- hitByWind()
) yield (combine (a3,a4))
主要是可读和可操作性好多了，你知道它是不变的，不可能会受其他future/thread的
影响。
还有，上面的结果也是future, 其实就是说,你还可以继续在其他地方拿它组合，完全
是对你透明的。 |
|
g*****g
发帖数: 34805 | 35 http://benchmarksgame.alioth.debian.org/u64q/csharp.php
真要对性能有兴趣，看看这个。C#性能比Java差多了。当然你可以推诿Mono实现得不好。
成天拿个boxing说事。就算实时trading有影响，99.99%的程序都不是实时trading，那
叫特例。
说到GC，我老倒是用Scala的Akka的时候发现大量的message造成频繁GC，为了最大化
throughput被迫在一些地方使用object pool。完全违背了Scala FP immutable的本意
。你就一新手，没啥实际经验，成天JJWW一些没意义的东西。不服倒是找个自己做过的
实际项目来证明JVM不行呀。 |
|
g*****g
发帖数: 34805 | 36 http://benchmarksgame.alioth.debian.org/u64q/csharp.php
真要对性能有兴趣，看看这个。C#性能比Java差多了。当然你可以推诿Mono实现得不好。
成天拿个boxing说事。就算实时trading有影响，99.99%的程序都不是实时trading，那
叫特例。
说到GC，我老倒是用Scala的Akka的时候发现大量的message造成频繁GC，为了最大化
throughput被迫在一些地方使用object pool。完全违背了Scala FP immutable的本意
。你就一新手，没啥实际经验，成天JJWW一些没意义的东西。不服倒是找个自己做过的
实际项目来证明JVM不行呀。 |
|
c******o
发帖数: 1277 | 37 反正两个都行，先写一个，然后再改。
这个需要做大量test的BDD/TDD，我们就这么干，好处是，到后面，效率和成果真的很
好，大家也都很有劲干。
实际中总是有一个侧重，基本上我们是能用FP的,能immutable就用，不然才imperative |
|
c******o
发帖数: 1277 | 38 说得不好，oo不知道，fp肯定有帮助，主要是immutability 和 更好的抽象包装。 |
|
p*****2
发帖数: 21240 | 39
node.js没有imuutability, 但是async, concurrency都很不错呀。而且我觉得
immutability性能可能不行，想优化的时候还是需要mutability, 所以Clojure和Scala
都有STM。 |
|
g*****g
发帖数: 34805 | 40 来自主题: Programming版 - 开源经济学 关系是有的，FP强调immutable, Scala为此提供了一整个collection。actor
framework
需要这个。另外就是大量async callback用lambda写比较简洁。
换句话说，akka用java实现不是不能，但没有scala实现起来优雅。 |
|
c******o
发帖数: 1277 | 41 今天卡看了一个slides，明白为啥我觉得akka没啥用。。。
http://www.slideshare.net/jboner/going-reactive-eventdriven-sca
Jonas Bonér TypeSafe CTO 做的， 里面讲了编写parallel时候可以用的工具（都很
流行啊）
1.先用immutability, future/data-flow 等语言直接支持的的工具,能并行够用就好
2.不够用，用Actor/Rx/Agent, 这类Async的分散式计算工具，这样可以有async的通讯。
3.不够用，必须有transaction,和share states, 就再加上STM
4.还不够用，那就只能上old Locks/显性thread 了。
我么只用到了 1/2之间，可能以后有3 |
|
c******o
发帖数: 1277 | 42 你保不保证各个async之间的message顺序？ 保证到达？ 保证互相之间执行的顺序？互
相之间通讯的那一部分。
这个解耦 可不简单，所以immutability好，要是以前的flow/algorithm不是并行的，那
么async有什么意义呢？有时候还要改flow/algorithm，这是编程的overhead
在 分散，并行系统里做到这样就会有overhead,你是fire and forget?还是guarantee
delivery? guarantee sequence?handle partial failure。 都是运行时候的overhead
.
如果在一个大的系统里，多用node会抵消这些overhead，带来好处，这就是
scalability.
要是本身一个两个node就解决了，那做这个干嘛？ |
|
c******o
发帖数: 1277 | 43 Just like normal people can much easier understand
how multiple parallel immutable transformation can compose with each other
than a completely mess of lock/semaphore/mutex.
like, |
|
g*****g
发帖数: 34805 | 44 FP强调immutable，这个东西做复杂多线程的东西确实是利器。用锁很容易出问题，而
且出问题了不容易debug。现在这波FP的Momentum，主要也在多线程的东西上。akka，
storm之类。
但推而广之说啥都适合FP就是瞎说了。FP比OOP出现得还早，要能流行早流行了。 |
|
p*****2
发帖数: 21240 | 45
嗯。去年用scala，不行可以上Java。这次用Clojure上mutable就不那么容易了。会强
迫写immutable的code了。 |
|
c******o
发帖数: 1277 | 46 最简单的就是例子就是，用 for loop/recursive 去实现同一个东西。
for loop mutable variable, recursive immutable value.
尤其是有些复杂的logic要求recursive的参数里带有函数。 |
|
c******o
发帖数: 1277 | 47 这个没比较啊，就是说Stream IO难懂，不好看。其实functional Stream IO的最重要
的优势还是composibility.
可以重用并且任意组合小的逻辑模块，而不用担心side effect.
Stream IO 其实确实是像他所说的，是个非常high level abstraction, 能做的可不光
是web service, 所有的IO side effect 都是可以用它来model
In short, you model "the whole world" as one or more Stream(s) (lazy
evaluate List) of events.
1. It is unlimited (a world never ends)
2. it can not go back (once you get a value, it is immutable, so it can not
be modified)
3. It is in future (before you see the value, it is not there)
再说，... 阅读全帖 |
|
k**********g
发帖数: 989 | 48
无论任何语言，都要掺一点函数式编程的精华(lambda, immutable, type system,
higher-order stuff)，又要提供一点编译器服务(runtime code synthesis)，才能应
付本世纪的电脑需要。 |
|
m******t
发帖数: 635 | 49 js的prototype-based programming似乎难用，要不coffeescript也不会给伪装一个。
JS号称也可以算fp, 不过感觉除了有first-class function这点外，其他的FP的主要特
点都缺：
immutability (JS code里mutable state漫天飞）
laziness (好像没听说JS有）
seq (clojure/F# 里都有，JS不知道，估计得第三方)
tail-call optimization （好像也没听说)
所以我觉得JS基本上是个伪FP, 当然OO也不方便 |
|
P********l
发帖数: 452 | 50 nodejs和akka/play在解决问题的思路上是不一样的．
akka把消息的接收／发送者实现成actor.一个actor可以发送／接受／转发很多种消息
．actor是immutable的，可以在不同的线程里或者机器里．
nodejs针对的是一系列的动作．比如，动作１完成触发动作２，动作２完成触发动作３
．这一些动作是异步的．在实现上，用的是promise那一套．
那些actor之间的消息和nodejs里的动作触发可以相比．actor里，并没有强调消息之间
有什么联系；nodejs的动作连续做完才是一件事情结束．
请各位大牛指正． |
|
