数学
约束
响应式



我觉得即使你完全不会函数式编程也该现场入门一下。。

每个点类存储一个变换函数，对于自变量来说，这个函数是设置时的闭包：

a=A(1,2)
得
a.x==lambda :1
a.y==lambda :2

对于因变量来说，这个函数是变换函数

c=a+b
得
c.x==lambda:a.x()+b.x()
c.y==lambda:a.y()+b.y()


当要取得 c 的值时调用 c.x()
=>(lambda:a.x()+b.x())()
=>(lambda:(lambda:1)()+(lambda:xb)())()
=>(lambda:1+xb)()


这不是比你递归通知约束对象计算新值要容易多了


至于怎么实现，约束方法本身已经是实现方法了，品一品

git 连 emoji 都支持，中文放心用

你看到的都是 N 年经验的社招面经

你见过应届写的面经吗？
应届是不是都不需要写代码？


你品一品

（诶？！那应届生都问啥？）

因果关系是这样的

人们并不知道光速不变是不是对的
但是如果假设有绝对时空，相对光做运动使用伽利略变换时，发现了矛盾
并且，如果假设有绝对时空，那么光在绝对静止的介质中运动时，应该能测量出某些性质

然而并没有测出来这个性质
所以绝对时空很可能是错的，光速能用伽利略变换可能也是错的


那好了，只能假设另一种情况了，假设光在任何参考系中速度都不变，以光速运动时观察光它还能相对你自己以光速运动

这个假设看起来匪夷所思，但也能推导出一系列结论，然后人们假设这些结论是对的，去做了一些实验观测，发现居然完美符合


那没办法，不信也不行，实验已经证明了

补充一下
copy 的语境，被 copy 的东西就是原来的，完全没变，而且 copy 的时候并不一定产生了结果（ copy - paste ）
duplicate 后，你一定得到了两份东西，是有结果的，而且这两份东西中是否一定有一份是原来的东西，并不一定，只是长得一样

比如 file copied，此时你并不预期 copy 成了哪个实体，也许会写到后面想起来再说的什么路径里去
但 file dupplicated 此时已经有两个一样的文件同时存在

把某个数据 duplicate 一下发往两个地方，很可能两个副本都 不是之前那份数据的引用
把某个数据 copy 到新地方，那肯定有一个是旧的引用本身




call invoke apply 区分得还是比较清楚的，直接调用叫 call，委托调用叫 invoke，把固定好的变换作用在不同对象上叫 apply

-or/-er 和 -ee 是主被动关系，这个不应该搞混才对

cache 有一个建议译名叫“快取”，很好地体现了这个词的原本定义

safety 和 security 并不好直接解释词义，开车这个语境比较容易分辨区别

copy 创造一个跟以前一样的实体
clone copy to new and likely for modifying
dupplicate 把原来的实体变成两个

call 执行任意形式的子过程并期待返回
invoke 代理给某个东西执行动作然后期待代理给我返回
apply 给一个对象应用一个变换器，尤其是函数。因此 apply 的语境相当函数式

iterator 用来访问集合的东西
-ee 被遍历的东西


buffer 存任意中间数据的地方
cache 用于加快访问而特意放置中间数据的地方


safety 开车撞车死不了
security 开车不会被劫持方向盘

还有一种方式是直接把 ip 地址算成线性空间，每个区间有左右界，合并的时候先按左界排序，然后判断
下一个区间的左界有没有落在前一个区间中，如果在，那么区间右界设成下一个区间右界，如果否，那么第一个区间已处理完毕，可以处理 23 区间

首先不考虑域名和 url

我当时的实现大概这样

一个 - 指定的范围可以解析成若干个 cidr 或 ip

那现在只需要考虑 cidr 一种情况（ ip 可以看做 /32 ）
用二叉 trie 来存这些 cidr，在深度为 N 的节点有一个 cidr 对象表示这个 cidr 是 /N

如果某个节点左右子树都存在则递归向上合并节点

插入过程中途遇到某个节点说明这节点已经包含了待插入地址，跳过

然后就没有去重这一说了，匹配就是走这个 trie 跟插入流程几乎一样的

当时没有去重合并完还要导出合并结果的需求

退休的没见过，财务自由早就可以退休了的见过不少

hhhh 之前有个同事比你这个聪明一点：

Button **btn = new ...
for(...)btn[...]= new ...

btn[0]->setText();
btn[0]->move(x,y)
...


btn[1]->...


问他为啥写屎他说这才是灵活的好代码，这样界面布局改了改坐标数字就行了，而且能随时加按钮

“这代码你看得出哪个是哪个吗”
“看 text 啊，你没用 ide 吗，看一下引用就知道是哪个了啊”

卧槽好像很有道理！

我昨天刚在笑话有人把监听当真，今天就又看到一个讨论监听的帖子
现在我信了，lz 监听我

random.shuffle

连 C++标准库都有类似的函数

从官方回复和其它网游经验来推测

你是不是买到了工作室出的钱或者装备什么的

我也面对过类似的重复工作。。 几十万行源码，几千个字符串，要从静态的改成可动态返回的


然后我
写了一个扫描特定格式字符串的脚本，把所有要替换的静态文本都收集了起来

写了一个扫描翻译文件（预先翻译好的文本对照）的脚本，把上一个脚本扫出来的东西转化成结构化的对{原文:翻译}格式，然后有些漏掉的手动修复

写了一段自动机描述程序（将被自动机生成器编译成 c 代码），这段程序能确保以 On 的效率搜索到原文对应的翻译结构

写了一堆宏和 wrapper 确保上面这个函数的调用能正确嵌入到原来字符串在的位置

还有一段脚本把原文件里的字符串换成上面的宏





最后这一大坨代码全部合在了一起变成了一个 translate.py 确保没有第二个人能看得懂怎么做到的 XD

虽然还是修了半天原文件里的字符串以让它变成能被脚本识别的特殊格式

但并不很枯燥无聊不是吗

emmmm 本来想 star 的，看了眼代码又关掉了

暴力匹配关键字 lexer
强行手写并不知道会不会符合语法定义的 parser

这个程度的 project 私以为随便做点现成语言的子集或者玩具语言就够了，意义不是很大
我觉得搞懂 bison 怎么写都比这个有成就感。。



就像 yin 神说的，写出来一个 parser 并不能完成什么里程碑

撸一撸自动机生成器或者接一下 llvm 实现一个编译型语言挑战大得多

jira.

不要忘了项目管理工具是为项目服务的

如果你们项目并不符合敏捷迭代的软件生命周期模型，那显然用不起来。我指的就那种做外包的、做传统软件的、一个项目大包解决方案先写几百页的瀑布流开发，那咋敏捷？连迭代都不需要，所有任务一个大表一块一块往小切，切不动花钱买，计划到头项目结束，完结了。这谁跟你看看板开站会哦

敏捷模型的典型场景是：
1. 你们小组经常需要交叉帮忙，没有固定 component 以及对应负责人
2. 需求池永远在增加，从不减少
3. 定期滚动发布，甚至每修一个 bug 就会发布一次