Luk*_*vat 6 haskell functional-programming
我一直在使用函数式编程已经有一段时间了,我觉得它很棒,所以我想教我的一些朋友Haskell.
不幸的是,我无法想到任何特定的代码片段来展示它们并说"看,这就是它看起来势在必行,看看功能有多好"
那么,那些比我更专业的人(这是一个非常低的要求)可以帮助我吗？
这似乎并不适合我,但如果是,请告诉我如何解决它.
可能最好的回归概念是所谓的"价值语义"和"纯度".
这些中的每一个都相互影响很大,在实践中很难将它们分开.然而,原则上,值语义意味着每个"事物"应该像值而不是对象.它导致更简单的传递,更少的"远距离幽灵行为"与有状态,并提供了一些背景来执行代码的等式推理.纯度意味着在您拥有代码的任何地方都不会出现副作用,而只是在仔细划分的点上.这意味着您的大多数代码最终都是独立且可重复使用的,而只有核心"应用程序"位与状态和效果深深地纠缠在一起.
你可能会说纯度在任何地方都有价值语义,或者价值是纯粹的计算 - 所以也许值得一提的是,"价值"指的是你的系统的名词(静态)和"纯度"的动词(动态).
众所周知,这些技术在其他语言中很有用.如今,OO语言中的一个常见想法就是由于组织和正确性的好处而乐于牺牲一些价值语义的速度.如果您对Haskell感到满意,那么您将了解如果将价值语义和纯度应用于整个程序的每个方面而不妥协,它们将如何工作.这意味着你已经接触过一些强大的模式来推理和构建纯粹的程序.
我一直在考虑进行比较的一个地方是免费monad和Command模式之间.两者都解决了非常类似的问题 - "我如何明确一个包含由程序执行的指令的结构,并在以后执行它,可能以各种方式执行？" - 但Command模式往往会在很多可变性中跳动至少,解释器,如果不是命令本身.
我们可以编写更像Free monads的Command模式吗？有什么好处？如果你有一个强大的Haskell背景,这些是你可以提出更多敏锐度的问题.
这是一个有趣且棘手的问题.一段时间以来,功能语言已成为命令式语言的概念趋势,功能/命令式语言之间的界限相当模糊.例如,假设您想要对列表中的每个元素进行平方xs并将结果存储在新列表中ys.
>> xs = [1, 2, 3] # Python
>> xs = [1, 2, 3] -- Haskell
如果您不了解功能习语,可以这样做:
>> ys = [0] * len(xs) # Python
>> for i in range(len(xs)):
ys[i] = xs[i] * xs[i]
在Haskell你只会写
>> ys = map (\x -> x * x) xs -- Haskell
当然,这个习惯用法也存在于Python中
>> ys = map(lambda x: x * x, xs) # Python
可以说,编写它的更好的方法是使用列表理解
>> ys = [x * x | x <- xs] -- Haskell
它也存在于Python中
>> ys = [x * x for x in xs] # Python
当然,功能方式比命令式方式更好(并且更可组合,更可重用).但在这种情况下,您不需要使用函数式语言来获得好处 - 您只需准备好"以功能性方式思考".