a*a
2 楼
从表面上来说，timesheet可谓真是有效催促员工工作的好办法，因为员工不能完成
timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
由不能charge太多，这样我只能用overhead，这样合理吗？
timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
由不能charge太多，这样我只能用overhead，这样合理吗？
T*x
3 楼
函数天然就能compose，无论是oop的函数还是fp的函数，也无论是有side effects的函
数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
模使用是从fp借鉴来的。这算一种思维方式的突破吗？
以上说的是一大特征。
另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
模使用是从fp借鉴来的。这算一种思维方式的突破吗？
以上说的是一大特征。
另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
y*h
4 楼
可以，刚这么办的。
m*u
5 楼
Find a place that's more reasonable.
【在 a*****a 的大作中提到】
: 从表面上来说，timesheet可谓真是有效催促员工工作的好办法，因为员工不能完成
: timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
: 可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
: 小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多，这样我只能用overhead，这样合理吗？
【在 a*****a 的大作中提到】
: 从表面上来说，timesheet可谓真是有效催促员工工作的好办法，因为员工不能完成
: timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
: 可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
: 小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多，这样我只能用overhead，这样合理吗？
m*r
6 楼
你的一些问题，dracdoc，海螺子，从实用角度，解释很多。
可以参考。
可以参考。
l*u
7 楼
Or find a new PM... It is a mutual choice... If no good PMs want you, try to
check what is wrong. Every consulting company use time sheet, time IS money
.
check what is wrong. Every consulting company use time sheet, time IS money
.
w*g
8 楼
写程序就是compose代码，确实和oop还是fp无关。
fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
这个说法原则上没错，但是实践上有很强的误导性。
让人觉得自己牛b了但实际上一点都没有更牛b。
一般来说对于某一个运算，必然存在数据以及处理数据的程序。
如果把程序看成数据，必然存在对应的运算，这个运算里
的数据是一段程序，而对应的程序是处理程序的程序。
这种“处理程序的程序”，实践中就是各种类似编译器的东西。
这也是为啥搞fp的人特别喜欢写编译器。
但是编译器和日常的数据处理差距太大了，只有在非常抽象
的层面上才能找到共同点，所以才搞出来各种abstract nonsense。
这些共同点对提高编程效率有多少帮助真是很不好讲。
而且这种抽象最多到一阶也就到顶了。我感觉
“处理处理程序的程序的程序”在实际工作中几乎不会备用到。想
个例子出来都难。
我觉得学FP最大的作用，就是一圈下来能够体会到图灵机是一个
多么伟大的发明。数据可以被修改这一点实践中非常关键。
如果就是搞lambda演算，后果就是1.硬件难做。2.程序难写。
程序就是写出来了，时间复杂度和空间复杂度也很难研究。
图灵机一举解决了两个问题。
immutable container在C++里实现完全没有问题，跟fp完全没关系。
C/C++里的const和function跟fp有关系么？
【在 T*******x 的大作中提到】
: 函数天然就能compose，无论是oop的函数还是fp的函数，也无论是有side effects的函
: 数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
: 种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
: 函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
: 模使用是从fp借鉴来的。这算一种思维方式的突破吗？
: 以上说的是一大特征。
: 另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
: 大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
: 确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
这个说法原则上没错，但是实践上有很强的误导性。
让人觉得自己牛b了但实际上一点都没有更牛b。
一般来说对于某一个运算，必然存在数据以及处理数据的程序。
如果把程序看成数据，必然存在对应的运算，这个运算里
的数据是一段程序，而对应的程序是处理程序的程序。
这种“处理程序的程序”，实践中就是各种类似编译器的东西。
这也是为啥搞fp的人特别喜欢写编译器。
但是编译器和日常的数据处理差距太大了，只有在非常抽象
的层面上才能找到共同点，所以才搞出来各种abstract nonsense。
这些共同点对提高编程效率有多少帮助真是很不好讲。
而且这种抽象最多到一阶也就到顶了。我感觉
“处理处理程序的程序的程序”在实际工作中几乎不会备用到。想
个例子出来都难。
我觉得学FP最大的作用，就是一圈下来能够体会到图灵机是一个
多么伟大的发明。数据可以被修改这一点实践中非常关键。
如果就是搞lambda演算，后果就是1.硬件难做。2.程序难写。
程序就是写出来了，时间复杂度和空间复杂度也很难研究。
图灵机一举解决了两个问题。
immutable container在C++里实现完全没有问题，跟fp完全没关系。
C/C++里的const和function跟fp有关系么？
【在 T*******x 的大作中提到】
: 函数天然就能compose，无论是oop的函数还是fp的函数，也无论是有side effects的函
: 数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
: 种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
: 函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
: 模使用是从fp借鉴来的。这算一种思维方式的突破吗？
: 以上说的是一大特征。
: 另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
: 大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
: 确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
a*l
9 楼
让它去死.项目花了多少时间就应该报多少时间,没有多报已经很对的起它了.不满意就
去找别人.
【在 a*****a 的大作中提到】
: 从表面上来说，timesheet可谓真是有效催促员工工作的好办法，因为员工不能完成
: timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
: 可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
: 小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多，这样我只能用overhead，这样合理吗？
去找别人.
【在 a*****a 的大作中提到】
: 从表面上来说，timesheet可谓真是有效催促员工工作的好办法，因为员工不能完成
: timesheet就面临要被裁的可能性，project manager也会被激励去管理好项目。
: 可是，我跟这个PM这么多年，每次项目最后都要超过budget，搞得比如我每周工作30个
: 小时，却只能charge一半，关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多，这样我只能用overhead，这样合理吗？
m*u
10 楼
P大点东西，至于么。。。。
c*2
11 楼
Your firm using low price to bid competing contract to begin with. So lots
of the time/cost will be in kind and you can only charge up to the budget in
the contract.
If you are full-time exempt, it doesn't matter to you. But for hourly
workers, firm transfers part of their burden to you by cutting your billable
hours.
of the time/cost will be in kind and you can only charge up to the budget in
the contract.
If you are full-time exempt, it doesn't matter to you. But for hourly
workers, firm transfers part of their burden to you by cutting your billable
hours.
m*o
12 楼
分析FP复杂度一点都不复杂，复杂的是如果FP本身自带默认non strictness，函数参数
被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
【在 w***g 的大作中提到】
: 写程序就是compose代码，确实和oop还是fp无关。
: fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
: 这个说法原则上没错，但是实践上有很强的误导性。
: 让人觉得自己牛b了但实际上一点都没有更牛b。
: 一般来说对于某一个运算，必然存在数据以及处理数据的程序。
: 如果把程序看成数据，必然存在对应的运算，这个运算里
: 的数据是一段程序，而对应的程序是处理程序的程序。
: 这种“处理程序的程序”，实践中就是各种类似编译器的东西。
: 这也是为啥搞fp的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了，只有在非常抽象
被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
【在 w***g 的大作中提到】
: 写程序就是compose代码，确实和oop还是fp无关。
: fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
: 这个说法原则上没错，但是实践上有很强的误导性。
: 让人觉得自己牛b了但实际上一点都没有更牛b。
: 一般来说对于某一个运算，必然存在数据以及处理数据的程序。
: 如果把程序看成数据，必然存在对应的运算，这个运算里
: 的数据是一段程序，而对应的程序是处理程序的程序。
: 这种“处理程序的程序”，实践中就是各种类似编译器的东西。
: 这也是为啥搞fp的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了，只有在非常抽象
m*o
13 楼
函数编程做expression reduction，常常可以通过等效原理获得大量的优化公式。这些
优化公式有等效原理作担保，会生成同样的结果。复杂度分析又证明可以获得更好的执
行速度。比如这个：
head . fmap f = f . head
对一个list先做map再取头值显然性能不如先取头值，在做转换。编译器如果发现程序
有如前者，根据等效原理直接可以替代成后者，不用写一堆测试来保证优化后结果必须
相同。
【在 m****o 的大作中提到】
: 分析FP复杂度一点都不复杂，复杂的是如果FP本身自带默认non strictness，函数参数
: 被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
: 种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
: reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
: 纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
: immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
: 在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
: 小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
优化公式有等效原理作担保，会生成同样的结果。复杂度分析又证明可以获得更好的执
行速度。比如这个：
head . fmap f = f . head
对一个list先做map再取头值显然性能不如先取头值，在做转换。编译器如果发现程序
有如前者，根据等效原理直接可以替代成后者，不用写一堆测试来保证优化后结果必须
相同。
【在 m****o 的大作中提到】
: 分析FP复杂度一点都不复杂，复杂的是如果FP本身自带默认non strictness，函数参数
: 被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
: 种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
: reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
: 纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
: immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
: 在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
: 小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
T*x
14 楼
从实用角度，我也是fp高手，不比那几个人差：）
【在 m******r 的大作中提到】
: 你的一些问题，dracdoc，海螺子，从实用角度，解释很多。
: 可以参考。
【在 m******r 的大作中提到】
: 你的一些问题，dracdoc，海螺子，从实用角度，解释很多。
: 可以参考。
m*r
15 楼
楼主说的compose, 指的是composite function,复合函数f(g(x))
你说的compose是创作的意思。
hadley wickham在R里面也是吹捧复合函数，举了很多例子，我看来都不太实用 （什么
延迟几秒执行另外一段程序）。 只有一个例子我记住了，就是求根。 一个函数负责求
根，另外一个函数负责把每次循环的x,y打出来， 我到今天都觉得很神奇。 就好比一
个人不到你们家， 能把你们家东西拿出来。
【在 w***g 的大作中提到】
: 写程序就是compose代码，确实和oop还是fp无关。
: fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
: 这个说法原则上没错，但是实践上有很强的误导性。
: 让人觉得自己牛b了但实际上一点都没有更牛b。
: 一般来说对于某一个运算，必然存在数据以及处理数据的程序。
: 如果把程序看成数据，必然存在对应的运算，这个运算里
: 的数据是一段程序，而对应的程序是处理程序的程序。
: 这种“处理程序的程序”，实践中就是各种类似编译器的东西。
: 这也是为啥搞fp的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了，只有在非常抽象
你说的compose是创作的意思。
hadley wickham在R里面也是吹捧复合函数，举了很多例子，我看来都不太实用 （什么
延迟几秒执行另外一段程序）。 只有一个例子我记住了，就是求根。 一个函数负责求
根，另外一个函数负责把每次循环的x,y打出来， 我到今天都觉得很神奇。 就好比一
个人不到你们家， 能把你们家东西拿出来。
【在 w***g 的大作中提到】
: 写程序就是compose代码，确实和oop还是fp无关。
: fp鼓吹函数/代码的第一性，认为代码应该和数据一样能被操作，
: 这个说法原则上没错，但是实践上有很强的误导性。
: 让人觉得自己牛b了但实际上一点都没有更牛b。
: 一般来说对于某一个运算，必然存在数据以及处理数据的程序。
: 如果把程序看成数据，必然存在对应的运算，这个运算里
: 的数据是一段程序，而对应的程序是处理程序的程序。
: 这种“处理程序的程序”，实践中就是各种类似编译器的东西。
: 这也是为啥搞fp的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了，只有在非常抽象
T*x
16 楼
一样。
【在 m******r 的大作中提到】
: 楼主说的compose, 指的是composite function,复合函数f(g(x))
: 你说的compose是创作的意思。
: hadley wickham在R里面也是吹捧复合函数，举了很多例子，我看来都不太实用 （什么
: 延迟几秒执行另外一段程序）。 只有一个例子我记住了，就是求根。 一个函数负责求
: 根，另外一个函数负责把每次循环的x,y打出来， 我到今天都觉得很神奇。 就好比一
: 个人不到你们家， 能把你们家东西拿出来。
【在 m******r 的大作中提到】
: 楼主说的compose, 指的是composite function,复合函数f(g(x))
: 你说的compose是创作的意思。
: hadley wickham在R里面也是吹捧复合函数，举了很多例子，我看来都不太实用 （什么
: 延迟几秒执行另外一段程序）。 只有一个例子我记住了，就是求根。 一个函数负责求
: 根，另外一个函数负责把每次循环的x,y打出来， 我到今天都觉得很神奇。 就好比一
: 个人不到你们家， 能把你们家东西拿出来。
g*t
17 楼
任何两个图灵机，都可以在一个通用图灵机上面跑，这是计算复杂度的基础。
在你的电脑上的O（n），在我的电脑上也是O（n），你想过这是为什么吗？
lambda没有这样的便利。
据我所知，直到十多年前我phd毕业。没有令人满意的lambda cost model。
假如有人发现这方面有大的改变，我会非常乐于学习。因为那可能是基础理论的一大进
步。
computation cost 这种概念，就像“热”一样，
人人都知道。但是要发展出来一个精确的，同时又可以用的
一个概念化，数量化的标度。那是极端困难的.
现在cost model只能在通用图灵机的基础上。
【在 m****o 的大作中提到】
: 分析FP复杂度一点都不复杂，复杂的是如果FP本身自带默认non strictness，函数参数
: 被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
: 种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
: reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
: 纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
: immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
: 在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
: 小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
在你的电脑上的O（n），在我的电脑上也是O（n），你想过这是为什么吗？
lambda没有这样的便利。
据我所知，直到十多年前我phd毕业。没有令人满意的lambda cost model。
假如有人发现这方面有大的改变，我会非常乐于学习。因为那可能是基础理论的一大进
步。
computation cost 这种概念，就像“热”一样，
人人都知道。但是要发展出来一个精确的，同时又可以用的
一个概念化，数量化的标度。那是极端困难的.
现在cost model只能在通用图灵机的基础上。
【在 m****o 的大作中提到】
: 分析FP复杂度一点都不复杂，复杂的是如果FP本身自带默认non strictness，函数参数
: 被lazily evaluated，这个时候分析复杂度会比较麻烦。haskell是迄今唯一这样的一
: 种语言。另外函数编程的优势在于程序的可理解性。lambda运算基于expression
: reduction，存学术角度出发程序运行的目的是不断被reduce到最后的结果，你拿一张
: 纸一支笔在纸上照样可以推算。这也是为什么FP要求referential transparency和
: immutable data，否则无法做context agnostic induction（1+1永远等于2，不管程序
: 在哪儿运行）。因为这样的特性，函数编程写出的程序即好理解也好维护，出错的概率
: 小。当然至于性能方面，FP一定被OOP好，没人打这样的保票。
g*t
18 楼
假如让你设计python的matlibplot，FP怎么做？
优化公式在哪里？
【在 m****o 的大作中提到】
: 函数编程做expression reduction，常常可以通过等效原理获得大量的优化公式。这些
: 优化公式有等效原理作担保，会生成同样的结果。复杂度分析又证明可以获得更好的执
: 行速度。比如这个：
: head . fmap f = f . head
: 对一个list先做map再取头值显然性能不如先取头值，在做转换。编译器如果发现程序
: 有如前者，根据等效原理直接可以替代成后者，不用写一堆测试来保证优化后结果必须
: 相同。
优化公式在哪里？
【在 m****o 的大作中提到】
: 函数编程做expression reduction，常常可以通过等效原理获得大量的优化公式。这些
: 优化公式有等效原理作担保，会生成同样的结果。复杂度分析又证明可以获得更好的执
: 行速度。比如这个：
: head . fmap f = f . head
: 对一个list先做map再取头值显然性能不如先取头值，在做转换。编译器如果发现程序
: 有如前者，根据等效原理直接可以替代成后者，不用写一堆测试来保证优化后结果必须
: 相同。
w*g
19 楼
你得到了它！
程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
, 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
换，得到形式上（编译器）和性能上（编译优化）的优化。
比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
多。
：一样。
：
程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
, 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
换，得到形式上（编译器）和性能上（编译优化）的优化。
比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
多。
：一样。
：
T*x
20 楼
magliner说我们说的compose不一样，我说的compose是函数复合，你说的compose是，
他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比如一个
程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其实顺序
执行的代码也可以由函数复合来实现。所以我说一样。
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比如一个
程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其实顺序
执行的代码也可以由函数复合来实现。所以我说一样。
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
g*t
21 楼
AI自己写程序是可以的。遗传算法很早就可以做。不过没什么business cases。我刚贴
了个链接就这个方向。自己改程序打游戏。
Fp都有固定点，相当于运行时可以有个eval. 那改一改，然后运行时再次Eval一下，就
可以了。我感觉C如果真要做其实应该也可以。
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实
上因为
没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规
则下的
等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行
时程序
自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越
来越远
。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个
fp语言
要牛的
: 多。
: ：一样。
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
了个链接就这个方向。自己改程序打游戏。
Fp都有固定点，相当于运行时可以有个eval. 那改一改，然后运行时再次Eval一下，就
可以了。我感觉C如果真要做其实应该也可以。
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实
上因为
没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规
则下的
等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行
时程序
自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越
来越远
。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个
fp语言
要牛的
: 多。
: ：一样。
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
g*t
22 楼
顺序执行的代码改复合在现实生活中往往有不可逾越的障碍。
: magliner说我们说的compose不一样，我说的compose是函数复合，你说的
compose是，
: 他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比
如一个
: 程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其
实顺序
: 执行的代码也可以由函数复合来实现。所以我说一样。
: ai
【在 T*******x 的大作中提到】
: magliner说我们说的compose不一样，我说的compose是函数复合，你说的compose是，
: 他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比如一个
: 程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其实顺序
: 执行的代码也可以由函数复合来实现。所以我说一样。
:
: ai
: magliner说我们说的compose不一样，我说的compose是函数复合，你说的
compose是，
: 他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比
如一个
: 程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其
实顺序
: 执行的代码也可以由函数复合来实现。所以我说一样。
: ai
【在 T*******x 的大作中提到】
: magliner说我们说的compose不一样，我说的compose是函数复合，你说的compose是，
: 他理解为，代码创作，包括程序的组织结构这些大方面的构建。我说一样是说比如一个
: 程序分两大段，先执行一段再执行一段，这是他所理解的你的compose代码。其实顺序
: 执行的代码也可以由函数复合来实现。所以我说一样。
:
: ai
n*p
23 楼
avoids changing-state and mutable data is the definition for FP. if a
language doesn't support that, it's not a FP language.
【在 T*******x 的大作中提到】
: 函数天然就能compose，无论是oop的函数还是fp的函数，也无论是有side effects的函
: 数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
: 种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
: 函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
: 模使用是从fp借鉴来的。这算一种思维方式的突破吗？
: 以上说的是一大特征。
: 另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
: 大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
: 确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
language doesn't support that, it's not a FP language.
【在 T*******x 的大作中提到】
: 函数天然就能compose，无论是oop的函数还是fp的函数，也无论是有side effects的函
: 数还是没有side effects的函数。所以fp鼓励函数composition的写法，这个应该算一
: 种编程风格，不能算本质吧？能看成是一种思维方式的突破吗？
: 函数本身作为参数传递，或者作为返回值返回，这个oop确实，不能说没有，但是大规
: 模使用是从fp借鉴来的。这算一种思维方式的突破吗？
: 以上说的是一大特征。
: 另一大特征就是immutable data了。变量没了，变成了tag，这确实是思维方式的一个
: 大转变。但这也不应该算是fp专利吧？fp你从名字上看，哪有提immutable data啊？它
: 确实大量使用不假。immutable data也可以和oop联系在一起，没有固有的障碍吧？
m*o
24 楼
Python这种被side effect深度浸润的语言，是没法采用等效原理的。还是我之前的那
个例子，先做map再取头值，假设函数本身的目的是将整数乘以2，但是为了方便调试，
设计者在函数里面还加了一行println（side effect），这样如果list长度是10，最后
的结果是屏幕上会有十行打印出现。而等式右边直接对头值最转换，只有一行打印。所
以等效原理在这儿已经失效。Haskell对于有side effect的函数统统封装成IO monad
，保证纯函数不可能有side effect，从而等效原理可以被适用。
【在 g****t 的大作中提到】
: 假如让你设计python的matlibplot，FP怎么做？
: 优化公式在哪里？
个例子，先做map再取头值，假设函数本身的目的是将整数乘以2，但是为了方便调试，
设计者在函数里面还加了一行println（side effect），这样如果list长度是10，最后
的结果是屏幕上会有十行打印出现。而等式右边直接对头值最转换，只有一行打印。所
以等效原理在这儿已经失效。Haskell对于有side effect的函数统统封装成IO monad
，保证纯函数不可能有side effect，从而等效原理可以被适用。
【在 g****t 的大作中提到】
: 假如让你设计python的matlibplot，FP怎么做？
: 优化公式在哪里？
m*o
25 楼
FP下面，函数的使用就像乐高积木一样，可以随意组合拆装，完全不用担心一个函数只
能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
【在 g****t 的大作中提到】
: 任何两个图灵机，都可以在一个通用图灵机上面跑，这是计算复杂度的基础。
: 在你的电脑上的O（n），在我的电脑上也是O（n），你想过这是为什么吗？
: lambda没有这样的便利。
: 据我所知，直到十多年前我phd毕业。没有令人满意的lambda cost model。
: 假如有人发现这方面有大的改变，我会非常乐于学习。因为那可能是基础理论的一大进
: 步。
: computation cost 这种概念，就像“热”一样，
: 人人都知道。但是要发展出来一个精确的，同时又可以用的
: 一个概念化，数量化的标度。那是极端困难的.
: 现在cost model只能在通用图灵机的基础上。
能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
【在 g****t 的大作中提到】
: 任何两个图灵机，都可以在一个通用图灵机上面跑，这是计算复杂度的基础。
: 在你的电脑上的O（n），在我的电脑上也是O（n），你想过这是为什么吗？
: lambda没有这样的便利。
: 据我所知，直到十多年前我phd毕业。没有令人满意的lambda cost model。
: 假如有人发现这方面有大的改变，我会非常乐于学习。因为那可能是基础理论的一大进
: 步。
: computation cost 这种概念，就像“热”一样，
: 人人都知道。但是要发展出来一个精确的，同时又可以用的
: 一个概念化，数量化的标度。那是极端困难的.
: 现在cost model只能在通用图灵机的基础上。
m*o
26 楼
scala 3 （dotty）的编译器将所有中间状况的AST全部转化成了immutable data，从而
开启了多线程编译程序的可能。当前的编译器（nsc）因为采用mutable ast，被锁死在
单线程编译。
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
开启了多线程编译程序的可能。当前的编译器（nsc）因为采用mutable ast，被锁死在
单线程编译。
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
n*p
27 楼
还有一个好处是如果无side effect的函数，结果可以被cache起来。如果有input一样
的，下次的结果不需要再次运算。这对于累积得很复杂的乐高式的函数，optimization
很可观。另外没有side effect的函数在多核的情况下，理论上不需要改code就可以自
动并行。
【在 m****o 的大作中提到】
: FP下面，函数的使用就像乐高积木一样，可以随意组合拆装，完全不用担心一个函数只
: 能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
: 成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
的，下次的结果不需要再次运算。这对于累积得很复杂的乐高式的函数，optimization
很可观。另外没有side effect的函数在多核的情况下，理论上不需要改code就可以自
动并行。
【在 m****o 的大作中提到】
: FP下面，函数的使用就像乐高积木一样，可以随意组合拆装，完全不用担心一个函数只
: 能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
: 成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
n*p
28 楼
你说的这个是Homoiconicity，但是lisp也确实是fp语言。
是AI语言，又是fp语言，这是lisp牛B的地方
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
是AI语言，又是fp语言，这是lisp牛B的地方
ai
【在 w***g 的大作中提到】
: 你得到了它！
: 程序自动compose函数，最多也只能以手工compose一样的规则进行。事实上因为没有ai
: , 目前把程序看做数据能做的非只读操作极其有限，基本上局限于给定规则下的等价变
: 换，得到形式上（编译器）和性能上（编译优化）的优化。
: 比较新的几个和编译器有关的项目，像halide, tvm这些也没有用fp.
: 我感觉lisp还是很牛的。牛在用list表示程序并且解释执行，提供了运行时程序自修改
: 的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
: 自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
: 多。
:
g*t
29 楼
网上有无数python实现的lisp，为啥等效原理python不能用？你在Python里面写lisp不
就可以了。
另外我这是想讨论个具体的例子，共时联想强的领域，fp设计是非常不合适的。
不管你用什么fp语言，我认为写data visualization的库都非常不方便。haskell一样。
因为人的脑子里面有chart。
【在 m****o 的大作中提到】
: Python这种被side effect深度浸润的语言，是没法采用等效原理的。还是我之前的那
: 个例子，先做map再取头值，假设函数本身的目的是将整数乘以2，但是为了方便调试，
: 设计者在函数里面还加了一行println（side effect），这样如果list长度是10，最后
: 的结果是屏幕上会有十行打印出现。而等式右边直接对头值最转换，只有一行打印。所
: 以等效原理在这儿已经失效。Haskell对于有side effect的函数统统封装成IO monad
: ，保证纯函数不可能有side effect，从而等效原理可以被适用。
就可以了。
另外我这是想讨论个具体的例子，共时联想强的领域，fp设计是非常不合适的。
不管你用什么fp语言，我认为写data visualization的库都非常不方便。haskell一样。
因为人的脑子里面有chart。
【在 m****o 的大作中提到】
: Python这种被side effect深度浸润的语言，是没法采用等效原理的。还是我之前的那
: 个例子，先做map再取头值，假设函数本身的目的是将整数乘以2，但是为了方便调试，
: 设计者在函数里面还加了一行println（side effect），这样如果list长度是10，最后
: 的结果是屏幕上会有十行打印出现。而等式右边直接对头值最转换，只有一行打印。所
: 以等效原理在这儿已经失效。Haskell对于有side effect的函数统统封装成IO monad
: ，保证纯函数不可能有side effect，从而等效原理可以被适用。
g*t
30 楼
这世界上哪里有这么便宜的事情。你多写写就明白了。
如果做产品，imperative,OO特性最后往往是必须的。
实际应用中，你从一个任务出发设计程序。但这些任务往往不适合
functional做。另外我前面讲了，两者之间有不可逾越的障碍。难度很大。
函数call和for loop互转的技术最早是图灵一个论文提出的。
代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
你可以从矩阵的cholesky分解什么的，lisp试着写一个安全可靠的矩阵求逆看看。
【在 m****o 的大作中提到】
: FP下面，函数的使用就像乐高积木一样，可以随意组合拆装，完全不用担心一个函数只
: 能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
: 成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
如果做产品，imperative,OO特性最后往往是必须的。
实际应用中，你从一个任务出发设计程序。但这些任务往往不适合
functional做。另外我前面讲了，两者之间有不可逾越的障碍。难度很大。
函数call和for loop互转的技术最早是图灵一个论文提出的。
代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
你可以从矩阵的cholesky分解什么的，lisp试着写一个安全可靠的矩阵求逆看看。
【在 m****o 的大作中提到】
: FP下面，函数的使用就像乐高积木一样，可以随意组合拆装，完全不用担心一个函数只
: 能在特定条件下（mutation）才能按设计状态工作。我觉得这是FP最大的贡献：函数变
: 成了数据，可以随便移动，随之而来的是对维护和理解压力的大大减轻。
m*o
31 楼
我不知道lisp具体是怎么回事，我也不知道等效原理在lisp下面是否也适用。等效原理
有两点要求：referential transparency和lazy evaluation。Haskell两点都满足。第
一点我相信lisp也可以做到，第二点我就不确定了。
样。
【在 g****t 的大作中提到】
: 网上有无数python实现的lisp，为啥等效原理python不能用？你在Python里面写lisp不
: 就可以了。
: 另外我这是想讨论个具体的例子，共时联想强的领域，fp设计是非常不合适的。
: 不管你用什么fp语言，我认为写data visualization的库都非常不方便。haskell一样。
: 因为人的脑子里面有chart。
有两点要求：referential transparency和lazy evaluation。Haskell两点都满足。第
一点我相信lisp也可以做到，第二点我就不确定了。
样。
【在 g****t 的大作中提到】
: 网上有无数python实现的lisp，为啥等效原理python不能用？你在Python里面写lisp不
: 就可以了。
: 另外我这是想讨论个具体的例子，共时联想强的领域，fp设计是非常不合适的。
: 不管你用什么fp语言，我认为写data visualization的库都非常不方便。haskell一样。
: 因为人的脑子里面有chart。
m*o
32 楼
FP bind(flatMap)就相当于imperative下的顺序执行。至于封装，FP下面用module +
type class就可以了。当然FP并不天生排斥OOP，Scala就是两者的融合。
【在 g****t 的大作中提到】
: 这世界上哪里有这么便宜的事情。你多写写就明白了。
: 如果做产品，imperative,OO特性最后往往是必须的。
: 实际应用中，你从一个任务出发设计程序。但这些任务往往不适合
: functional做。另外我前面讲了，两者之间有不可逾越的障碍。难度很大。
: 函数call和for loop互转的技术最早是图灵一个论文提出的。
: 代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
: 你可以从矩阵的cholesky分解什么的，lisp试着写一个安全可靠的矩阵求逆看看。
type class就可以了。当然FP并不天生排斥OOP，Scala就是两者的融合。
【在 g****t 的大作中提到】
: 这世界上哪里有这么便宜的事情。你多写写就明白了。
: 如果做产品，imperative,OO特性最后往往是必须的。
: 实际应用中，你从一个任务出发设计程序。但这些任务往往不适合
: functional做。另外我前面讲了，两者之间有不可逾越的障碍。难度很大。
: 函数call和for loop互转的技术最早是图灵一个论文提出的。
: 代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
: 你可以从矩阵的cholesky分解什么的，lisp试着写一个安全可靠的矩阵求逆看看。
g*t
33 楼
十几年前我phd时候写了五年mathematica。至今我没见到过比mathematica更强大的
flat list。
根据我的经验，函数bind转化成for loop在理论上没有问题。图灵证明过了。但是在实
际中有不可逾越的困难。
我举的最简单的例子。你写个矩阵求逆就明白了。
我个人的判断。把线性代数基本库转成函数式的库完全可行。
而且也有实际意义。但是那不是一两个phd可以完成的事情。
【在 m****o 的大作中提到】
: FP bind(flatMap)就相当于imperative下的顺序执行。至于封装，FP下面用module +
: type class就可以了。当然FP并不天生排斥OOP，Scala就是两者的融合。
flat list。
根据我的经验，函数bind转化成for loop在理论上没有问题。图灵证明过了。但是在实
际中有不可逾越的困难。
我举的最简单的例子。你写个矩阵求逆就明白了。
我个人的判断。把线性代数基本库转成函数式的库完全可行。
而且也有实际意义。但是那不是一两个phd可以完成的事情。
【在 m****o 的大作中提到】
: FP bind(flatMap)就相当于imperative下的顺序执行。至于封装，FP下面用module +
: type class就可以了。当然FP并不天生排斥OOP，Scala就是两者的融合。
n*p
34 楼
majority of sequence operations in clojure are lazy,
sometimes you have to use doall functions to force the evaluation.
http://clojuredocs.org/clojure.core/doall
【在 m****o 的大作中提到】
: 我不知道lisp具体是怎么回事，我也不知道等效原理在lisp下面是否也适用。等效原理
: 有两点要求：referential transparency和lazy evaluation。Haskell两点都满足。第
: 一点我相信lisp也可以做到，第二点我就不确定了。
:
: 样。
sometimes you have to use doall functions to force the evaluation.
http://clojuredocs.org/clojure.core/doall
【在 m****o 的大作中提到】
: 我不知道lisp具体是怎么回事，我也不知道等效原理在lisp下面是否也适用。等效原理
: 有两点要求：referential transparency和lazy evaluation。Haskell两点都满足。第
: 一点我相信lisp也可以做到，第二点我就不确定了。
:
: 样。
相关阅读
How solid it is: c++/c# call Matlab libraryC++的很多library到底是趋于集中，还是各个公司独自开发，各立山头windows 7 automation tool for newbie: bat, cygwin or pythonMemory Usage问题自学了 java scriptpython用什么做gui?问一个GWT里面CellBrowser无法在VerticalPanel/HorizontalPanel里面显示的问题Is it safe to use unique_ptr with STL container?sencha ext js搞定客户端网页。请教Intel MPI基本常识我写了这个iPhone"买买提""阅读器Python下面有没有类似Magento的开源网店？凑个热闹也说CS (转载)大家从server push数据到client side,用啥办法好些？abs((int)-2147483648)是负数，如何 解释？Go lua 有人比较下么怎样的构架才算Private Cloud?yahoo的Dan Loeb退了。amazon 的 aws 是用什么语言开发的？买了Sedgewick, Robert的Algorithm in C++