zoukankan      html  css  js  c++  java
  • 关于首页上的几个话题

    汇编与IL:老赵给的视角非常不错,受用了。

    不过关于CLR内幕,我这里有一个问题,这些细节,大多数人知道它干吗?

    如果一个项目不under the hood不行了,我肯定滚去使用C/C++了...

    我不是提什么反对意见,我是想知道具体场景。

    关于算法:回复中支持算法的兄弟们说的都很不错。

    实际上,这里头最关键的一点是我们先要明白,算法没多难,也许之后再明白,数学没多难(没做到)。

    具体说到大多数从业人员,算法造诣确实不是必需的;不过没有算法你也要有其他的东西。

    我们不可能解决所有问题,但很擅长解决某一类,就是我们的特色了。

    说到底还是一个(决定自己)价值体现在哪里的问题;尤其是硬骨头,永远免不了。

     


    说点自己的事情。

    一个对象,你给他什么操作,很多时候确实很难决断。

    很早就说过,简单的“主语.谓语”式OO根本搞不定复杂的问题:缺乏有指导作用的建模方法。

    存在多种看待问题的视角是很自然的事情,关键在于我们根据怎样的原则在其中挑选。

    一些经验:相对于其它原则,代之以层次去决定操作如何在对象间安排。

    为什么?因为抽象之前就要回答:关心的是哪个层次。

    为什么我又开始说对象呢?因为我降低了函数式的使用程度和深度。

    我要开始反思和总结过去一年的函数式热了。

    初步体会,关键不在于函数式不能干什么,而在于某一个风格对我们的导向。

    当你把一个函数的自变量和因变量其本身设计的足够合适,就会发现纯函数式风格的糖豆未免太少了些。

    糖豆不应仅只是方便,也意味着一个更好的说明意图的方式。

    切掉高阶函数等从非函数式看是糖豆的东西,在函数式风格上的挖掘又带给我们什么呢?

    风潮本身给毫无顾忌的状态使用刹了车,提醒我们习惯之外的合理做法。【1】

    我们应该时刻衡量一个状态的产生有无必要性,在空间和时间上有什么影响,尤其是沿什么路径传播的。

    空间主要是指状态在数据结构之间,而时间在这里指的却是项目的成长期。

    从这个角度来看,函数式的重新兴起是有意义的。

    非函数式风格的难题在于交错的状态,反过来函数式风格的关键在于如何安排好数据结构之间的关系。

    搭配?其实不是一件非常必要的事情。糖豆级的使用也说不上什么搭配。

    一个合理的风格选择的衡量标准,恐怕是可读性。

    如果自己读自己的程序,看起来不像一个傻瓜写的,那么也许切换些风格是不错的选择。

    毕竟,在KISS面前,没有任何借口。

     


    update:

    注释【1】:

    说点和大家相关的,回忆起以前的贫血模型、静态方法的讨论,不得不承认,在很多情况下这是增一分则多的方案。

    我过去使用的方法是退化模型,就是我认为简单的结构是通过更复杂的退化得来的会比较舒服。

    但这样在前期似乎不必要的工作量大了一些,相反“进化”在后期又可能痛苦。

    上文说“习惯之外”,但这个“架构”恰恰在很多人习惯之内;只是有人总担心它太简单,然后担心又成为了习惯。

    说这些不代表我支持某种风格的开发过程;只是这个问题,关乎于学习和实践,值得玩味。

    update again:

    由此想到,果然多范式运用再加上动态语言(最近用的python)也无法找到我想要的那种感觉。粘合和进化还是两码事情。

    只可惜我不能以目前的生存状态一直持续下去,这样在语言设计上的学习、尝试,只能一推再推,不爽。

  • 相关阅读:
    洛谷 P1387 最大正方形
    洛谷 P1508 Likecloud-吃、吃、吃
    洛谷 P1282 多米诺骨牌
    洛谷 P1880 [NOI1995]石子合并
    P1064 金明的预算方案 (依赖性背包问题)
    caioj 1114 树形动态规划(TreeDP)3.0:多叉苹果树【scy改编ural1018二叉苹果树】
    让Dev C++支持C++11
    1113: [视频]树形动态规划(TreeDP)8:树(tree)(树形dp状态设计总结)
    caioj 1112 树形动态规划(TreeDP)7:战略游戏
    caioj 1111 树形动态规划(TreeDP)6: 皇宫看守 (状态设计)
  • 原文地址:https://www.cnblogs.com/guaiguai/p/1495389.html
Copyright © 2011-2022 走看看