日历

September 2020
M T W T F S S
 123456
78910111213
14151617181920
21222324252627
282930  

FP

Tagged: 

  • This topic is empty.
Viewing 1 reply thread
  • Author
    Posts
    • #1136
      Lumj
      Member

      近一月翻来很多关于语言与范式的书(这归功于冒号课堂:))来看,觉得很有意思

      尤其是对于FP,很诱人,因为了解到它与命令式语言描述问题的方式的对偶关系,使我觉得,它与命令式的互补一定能发挥强大的威力

      后来我找来个scheme玩了一下

      现在我正尝试把FP应用到日常开发当中,我初步的想法是,将状态映射(计算)与状态改变(赋值,side effect)有意识地清晰地分开,并分别以FP与IP(imperative pro..,有这个词吧??)实现,具体地,Object的本性是维持状态,于是我设想在 单个方法体内的局部计算 或是 查询类方法的整体 这样的无状态瞬间应用纯FP——当然是尽可能地,因为由于需要依赖环境的代码以及问题本身的特性等等,也是有可能不适合FP做的——我想也许这样的实践会很自然地促使对代码的清晰理解和合理轻便(对了,还有正交)的设计(有点像DbC促使人意识到query与command的分离那样)

      我是在一个使用c#的工程(我自己开发着玩的东西)中作这样的尝试的,昨天我的代码一下呈现出和以前很不一样的风格,感觉很不错..

      我感觉维护控制流的状态的逻辑是一个在普通IP过程中一直被隐性地重复描述着的逻辑(比如标记某个循环的退出是循环个某个条件成立导致的还是先达循环终点时的自然结束并作不同处理)

      还有,空逻辑(我把它叫nulling)也是:根据某个值是否为0或null还是有内容来制造出一个新值——比如为0或false就生成一个新的null(下级以0体现空,本级由于其返回值等因素需要以null来体现’空’),否则就利用那个内容计算出一个新的有内容的对象,这类逻辑也是被无限期地隐性重复着

      我感觉这类现象是导致错误和降低生产力的一类因素,因为同一件事每次都要描述一遍(而且有的本身就容易出错),自然带来出错的可能性,而在我的FP实践中,这类事就(几乎)可以完全消除,使我感觉代码很纯净

      感受很多,所以写到这里我也不知道有没有偏题,上面说的这类因素是否和FP有必然的关联我也还不好说.好,就到这吧

    • #1360
      hui
      Keymaster

      你这种想法和尝试非常好。将程序中的有副作用与无副作用的部分分离,是一种很好的做法。一方面,他们很可能属于不同的关注点,符合SoC原则;另一方面,这对代码的维护、调试、处理多线程等方面都不无裨益。顺便说一句,无副作用模块之所以可贵,最重要的原因是它对时间的脱耦性。

Viewing 1 reply thread
  • You must be logged in to reply to this topic.
 请您评分1星(很差)2星(不行)3星(一般)4星(不错)5星(很棒)