avatar
m*r
1
准备他们10月初来,但是如果9月底等签证过期了再去,就有点晚了,机票什么的也贵
,想问一下能不能在签证过期之前去续签呢?谢谢
avatar
a*a
2
从表面上来说,timesheet可谓真是有效催促员工工作的好办法,因为员工不能完成
timesheet就面临要被裁的可能性,project manager也会被激励去管理好项目。
可是,我跟这个PM这么多年,每次项目最后都要超过budget,搞得比如我每周工作30个
小时,却只能charge一半,关键没有billable hours我也没办法活命啊。他说出各种理
由不能charge太多,这样我只能用overhead,这样合理吗?
avatar
T*x
3
函数天然就能compose,无论是oop的函数还是fp的函数,也无论是有side effects的函
数还是没有side effects的函数。所以fp鼓励函数composition的写法,这个应该算一
种编程风格,不能算本质吧?能看成是一种思维方式的突破吗?
函数本身作为参数传递,或者作为返回值返回,这个oop确实,不能说没有,但是大规
模使用是从fp借鉴来的。这算一种思维方式的突破吗?
以上说的是一大特征。
另一大特征就是immutable data了。变量没了,变成了tag,这确实是思维方式的一个
大转变。但这也不应该算是fp专利吧?fp你从名字上看,哪有提immutable data啊?它
确实大量使用不假。immutable data也可以和oop联系在一起,没有固有的障碍吧?
avatar
y*h
4
可以,刚这么办的。
avatar
m*u
5
Find a place that's more reasonable.

【在 a*****a 的大作中提到】
: 从表面上来说,timesheet可谓真是有效催促员工工作的好办法,因为员工不能完成
: timesheet就面临要被裁的可能性,project manager也会被激励去管理好项目。
: 可是,我跟这个PM这么多年,每次项目最后都要超过budget,搞得比如我每周工作30个
: 小时,却只能charge一半,关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多,这样我只能用overhead,这样合理吗?

avatar
m*r
6
你的一些问题,dracdoc,海螺子,从实用角度,解释很多。
可以参考。
avatar
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
.
avatar
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联系在一起,没有固有的障碍吧?

avatar
a*l
9
让它去死.项目花了多少时间就应该报多少时间,没有多报已经很对的起它了.不满意就
去找别人.

【在 a*****a 的大作中提到】
: 从表面上来说,timesheet可谓真是有效催促员工工作的好办法,因为员工不能完成
: timesheet就面临要被裁的可能性,project manager也会被激励去管理好项目。
: 可是,我跟这个PM这么多年,每次项目最后都要超过budget,搞得比如我每周工作30个
: 小时,却只能charge一半,关键没有billable hours我也没办法活命啊。他说出各种理
: 由不能charge太多,这样我只能用overhead,这样合理吗?

avatar
m*u
10
P大点东西,至于么。。。。
avatar
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.
avatar
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的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了,只有在非常抽象

avatar
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好,没人打这样的保票。

avatar
T*x
14
从实用角度,我也是fp高手,不比那几个人差:)

【在 m******r 的大作中提到】
: 你的一些问题,dracdoc,海螺子,从实用角度,解释很多。
: 可以参考。

avatar
m*r
15
楼主说的compose, 指的是composite function,复合函数f(g(x))
你说的compose是创作的意思。
hadley wickham在R里面也是吹捧复合函数,举了很多例子,我看来都不太实用 (什么
延迟几秒执行另外一段程序)。 只有一个例子我记住了,就是求根。 一个函数负责求
根,另外一个函数负责把每次循环的x,y打出来, 我到今天都觉得很神奇。 就好比一
个人不到你们家, 能把你们家东西拿出来。

【在 w***g 的大作中提到】
: 写程序就是compose代码,确实和oop还是fp无关。
: fp鼓吹函数/代码的第一性,认为代码应该和数据一样能被操作,
: 这个说法原则上没错,但是实践上有很强的误导性。
: 让人觉得自己牛b了但实际上一点都没有更牛b。
: 一般来说对于某一个运算,必然存在数据以及处理数据的程序。
: 如果把程序看成数据,必然存在对应的运算,这个运算里
: 的数据是一段程序,而对应的程序是处理程序的程序。
: 这种“处理程序的程序”,实践中就是各种类似编译器的东西。
: 这也是为啥搞fp的人特别喜欢写编译器。
: 但是编译器和日常的数据处理差距太大了,只有在非常抽象

avatar
T*x
16
一样。

【在 m******r 的大作中提到】
: 楼主说的compose, 指的是composite function,复合函数f(g(x))
: 你说的compose是创作的意思。
: hadley wickham在R里面也是吹捧复合函数,举了很多例子,我看来都不太实用 (什么
: 延迟几秒执行另外一段程序)。 只有一个例子我记住了,就是求根。 一个函数负责求
: 根,另外一个函数负责把每次循环的x,y打出来, 我到今天都觉得很神奇。 就好比一
: 个人不到你们家, 能把你们家东西拿出来。

avatar
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好,没人打这样的保票。

avatar
g*t
18
假如让你设计python的matlibplot,FP怎么做?
优化公式在哪里?

【在 m****o 的大作中提到】
: 函数编程做expression reduction,常常可以通过等效原理获得大量的优化公式。这些
: 优化公式有等效原理作担保,会生成同样的结果。复杂度分析又证明可以获得更好的执
: 行速度。比如这个:
: head . fmap f = f . head
: 对一个list先做map再取头值显然性能不如先取头值,在做转换。编译器如果发现程序
: 有如前者,根据等效原理直接可以替代成后者,不用写一堆测试来保证优化后结果必须
: 相同。

avatar
w*g
19
你得到了它!
程序自动compose函数,最多也只能以手工compose一样的规则进行。事实上因为没有ai
, 目前把程序看做数据能做的非只读操作极其有限,基本上局限于给定规则下的等价变
换,得到形式上(编译器)和性能上(编译优化)的优化。
比较新的几个和编译器有关的项目,像halide, tvm这些也没有用fp.
我感觉lisp还是很牛的。牛在用list表示程序并且解释执行,提供了运行时程序自修改
的可能。这个牛b之处我感觉和fp也没太大关系。后来fp发展也离这个越来越远。程序
自修改理论也还是70年前的萌芽状态。lisp作为一个AI语言比它作为一个fp语言要牛的
多。

:一样。
avatar
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语言要牛的
: 多。
:

avatar
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语言要牛的
: 多。
:

avatar
g*t
22
顺序执行的代码改复合在现实生活中往往有不可逾越的障碍。


: magliner说我们说的compose不一样,我说的compose是函数复合,你说的
compose是,

: 他理解为,代码创作,包括程序的组织结构这些大方面的构建。我说一样是说比
如一个

: 程序分两大段,先执行一段再执行一段,这是他所理解的你的compose代码。其
实顺序

: 执行的代码也可以由函数复合来实现。所以我说一样。

: ai



【在 T*******x 的大作中提到】
: magliner说我们说的compose不一样,我说的compose是函数复合,你说的compose是,
: 他理解为,代码创作,包括程序的组织结构这些大方面的构建。我说一样是说比如一个
: 程序分两大段,先执行一段再执行一段,这是他所理解的你的compose代码。其实顺序
: 执行的代码也可以由函数复合来实现。所以我说一样。
:
: ai

avatar
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联系在一起,没有固有的障碍吧?

avatar
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怎么做?
: 优化公式在哪里?

avatar
m*o
25
FP下面,函数的使用就像乐高积木一样,可以随意组合拆装,完全不用担心一个函数只
能在特定条件下(mutation)才能按设计状态工作。我觉得这是FP最大的贡献:函数变
成了数据,可以随便移动,随之而来的是对维护和理解压力的大大减轻。

【在 g****t 的大作中提到】
: 任何两个图灵机,都可以在一个通用图灵机上面跑,这是计算复杂度的基础。
: 在你的电脑上的O(n),在我的电脑上也是O(n),你想过这是为什么吗?
: lambda没有这样的便利。
: 据我所知,直到十多年前我phd毕业。没有令人满意的lambda cost model。
: 假如有人发现这方面有大的改变,我会非常乐于学习。因为那可能是基础理论的一大进
: 步。
: computation cost 这种概念,就像“热”一样,
: 人人都知道。但是要发展出来一个精确的,同时又可以用的
: 一个概念化,数量化的标度。那是极端困难的.
: 现在cost model只能在通用图灵机的基础上。

avatar
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语言要牛的
: 多。
:

avatar
n*p
27
还有一个好处是如果无side effect的函数,结果可以被cache起来。如果有input一样
的,下次的结果不需要再次运算。这对于累积得很复杂的乐高式的函数,optimization
很可观。另外没有side effect的函数在多核的情况下,理论上不需要改code就可以自
动并行。

【在 m****o 的大作中提到】
: FP下面,函数的使用就像乐高积木一样,可以随意组合拆装,完全不用担心一个函数只
: 能在特定条件下(mutation)才能按设计状态工作。我觉得这是FP最大的贡献:函数变
: 成了数据,可以随便移动,随之而来的是对维护和理解压力的大大减轻。

avatar
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语言要牛的
: 多。
:

avatar
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,从而等效原理可以被适用。

avatar
g*t
30
这世界上哪里有这么便宜的事情。你多写写就明白了。
如果做产品,imperative,OO特性最后往往是必须的。
实际应用中,你从一个任务出发设计程序。但这些任务往往不适合
functional做。另外我前面讲了,两者之间有不可逾越的障碍。难度很大。
函数call和for loop互转的技术最早是图灵一个论文提出的。
代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
你可以从矩阵的cholesky分解什么的,lisp试着写一个安全可靠的矩阵求逆看看。

【在 m****o 的大作中提到】
: FP下面,函数的使用就像乐高积木一样,可以随意组合拆装,完全不用担心一个函数只
: 能在特定条件下(mutation)才能按设计状态工作。我觉得这是FP最大的贡献:函数变
: 成了数据,可以随便移动,随之而来的是对维护和理解压力的大大减轻。

avatar
m*o
31
我不知道lisp具体是怎么回事,我也不知道等效原理在lisp下面是否也适用。等效原理
有两点要求:referential transparency和lazy evaluation。Haskell两点都满足。第
一点我相信lisp也可以做到,第二点我就不确定了。

样。

【在 g****t 的大作中提到】
: 网上有无数python实现的lisp,为啥等效原理python不能用?你在Python里面写lisp不
: 就可以了。
: 另外我这是想讨论个具体的例子,共时联想强的领域,fp设计是非常不合适的。
: 不管你用什么fp语言,我认为写data visualization的库都非常不方便。haskell一样。
: 因为人的脑子里面有chart。

avatar
m*o
32
FP bind(flatMap)就相当于imperative下的顺序执行。至于封装,FP下面用module +
type class就可以了。当然FP并不天生排斥OOP,Scala就是两者的融合。

【在 g****t 的大作中提到】
: 这世界上哪里有这么便宜的事情。你多写写就明白了。
: 如果做产品,imperative,OO特性最后往往是必须的。
: 实际应用中,你从一个任务出发设计程序。但这些任务往往不适合
: functional做。另外我前面讲了,两者之间有不可逾越的障碍。难度很大。
: 函数call和for loop互转的技术最早是图灵一个论文提出的。
: 代入实践你试试就知道了。写的略多就一定会碰到无法转的情况。
: 你可以从矩阵的cholesky分解什么的,lisp试着写一个安全可靠的矩阵求逆看看。

avatar
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就是两者的融合。

avatar
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也可以做到,第二点我就不确定了。
:
: 样。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。