FrankHB 最近的时间轴更新
↓挽……
79 天前
FrankHB

FrankHB

V2EX 第 34994 号会员,加入于 2013-02-28 10:06:28 +08:00
今日活跃度排名 12020
FrankHB 最近回复了
……你这标题。。我还以为现在微信已经流氓到卸载也需要专用定制方案了。
2 天前
回复了 Salticey 创建的主题 奇思妙想 纠正错误是人类的原始冲动吗?
@kop1989smurf 未必,也可能只是想打死异教徒维护自身生存环境安全类似的心理而已。
2 天前
回复了 plko345 创建的主题 程序员 是不是 gc 过程都会导致应用暂停
@Kould 即使使用得当,不限深度的嵌套数据结构集中释放也很容易出现高延迟的问题。(这不属于使用不当,因为语言允许轻易地构造这种对象。)
实际上不容易观察到类似的问题,是因为在此之前,大多数 naive 实现在递归调用释放资源的例程中就直接爆栈了(
2 天前
回复了 plko345 创建的主题 程序员 是不是 gc 过程都会导致应用暂停
不一定,现代的一些 GC 实现可以并发回收,暂停个别线程而不是整个进程。实用上(暂停时间能保证短至分时系统的个别时间片粒度)只影响 GC 线程而完全避免阻塞应用线程的实现很少,像 Asul C4 。代价是感人的内存使用率。
C/C++之类用全局堆之类实现的自由存储一样不能完全避免对全局共享的分配器内部管理数据结构加锁而可能暂停,但是任何靠谱的实现中这个暂停相对几乎所有 GC 都非常短而基本可以忽略。一些实现如 snmalloc 在同一个线程中的分配和释放可以完全不暂停其它线程。用户实现的只对特定线程可用的分配器可以不影响其它线程。
以上 GC 专指全局 tracing GC 。多实例 GC 堆和引用计数对整个应用的影响在此都可以视同后者。
当然如果程序是单线程的,那么不管是 GC 还是确定性分配器都会直接阻塞,因为没什么实现无聊到在释放算法里实现分时多任务。
2 天前
回复了 kongkongye 创建的主题 程序员 spring 的约定优于配置概念好吗?
没约定还不是一样要看文档来配置……
约定烂是另一回事,属于设计问题。
2 天前
回复了 fpure 创建的主题 程序员 这算不算是静态类型系统的缺憾
再借楼发(跑)散(题)超纲一点,我想特别显示一下在 lang spec 里钦定 phase 这个做法的实际历史性后果,以说明它是如何比 PL 壬沉溺(钦定设计的) type system 和相关研究更优先值得黑的。

钦定 phase 的一个显著后果单方面由语言设计者决定了何为“静态”,而没有用户议价的空间,导致不切实际的无效工作。
一旦不满足用户需要,要维持可编程性,就需要 ad-hoc (致敬 ad-hoc polymorphism ,表示“不一定就是坏的”,但实际大家都懂的)的 reflection 机制来变通。
这种机制基本也只可能由 spec 钦定,于是设计语言时就凭空多出来本不必要的一大坨的 API 设计(经常还没法避免主观性,特别是甄选什么 feature subset 配被 reflect )的工作:工作量大体 O(n^t),其中 t 是 phase 数,常量和其它特性正相关。(虽然大 O 是渐进上界,但常数可不小,一般要可用也够受的了。)
大部分语言中 t=2 ,被隐含钦定的 phase 是 phase of translation 和 phase of execution 两个,这也是一般所谓语言是否可被视为“静态”的分野。光是这个就制造出了反射这种原本就是同一个直接语义直接元编程的就能“免费”实现(源语言语法满足 homoiconicity 时)的工作。而 C/C++这种直接钦定一大坨 phase 的做法更加突出了所谓 compilation-time reflection 的更欠抽的“高阶”无谓设计和实现工作量。(当然,C 一直装死摆烂,这里可以算了。)(还好,除了 C++主流语言里还有谁那么乱的么……)
第二个后果是简单粗暴的 phase 蕴含了粗放式分层架构,即便实际的需求中,各个 phase 的问题域具有局域性,而并不要求语言规则具有明确的分层结构。
这是 reflection 这样的机制难以被其它形式的元编程替代的另一个原因。
这里有个类型系统外过于“静态”的例子:hygienic macro 再强,就算 host lang 再 homoiconic ,基本也得多一个 template sublanguage (而增加无谓设计和用户学习的工作量)——很大程度是多了个 expansion-time phase 的锅。
作为对比,bind-time analysis 中多出来的就是 local stage ,不添加类似的缺陷。
第三个后果是对实现结构的影响(不过其实 C 这种传统设计其实算是直接泄漏了实现的设计),尤其是造成片面拔高 AOT 编译的能力的偏见,工程上力大砖飞,搞不好就加人,全然不管项目规模扩大的代价,特别是路径依赖。
(幸甚,multi-staged ML/reflective Lisp 之流从来不成气候,所以毒害的主要也就局限在传统“静态”语言实现了……)
当年编译器理论界对 nanopass 的普遍怀疑也说明这不仅仅是工业界见识短的问题,“理论界”也整体就跑偏了。
近年来 PyPy 和 Graal+Truffle 这样更正统(指 variants of Futamura projection )的计科传统艺能(指无情地自动化加抽象)重新上线,让一些实现者认识到现有方法论的欠缺(你人再多能打得过自动化翻译解释器成量产优化编译器么),算是自底向上地打了脸。
遗憾的是,这个问题在工业界距离彻底纠正差得远了:可预见的未来内要指望主流工业界开窍避免依赖 GCC 和 LLVM 这样的力大砖飞式历史包袱是十分不现实的。

其它理论碎碎念:github.com/FrankHB/pl-docs/blob/master/en-US/calling-for-language-features.md#phases-and-stages (关于这些问题如何破坏语言的通用性,Ctrl+F smoothness 。)
3 天前
回复了 fpure 创建的主题 程序员 这算不算是静态类型系统的缺憾
@dangyuluo 这就是哪壶不开提哪壶了,C++的那种强 phase (of translation)隔离的做法反而是最让我火大的糟心解。
虽然表面没 OP 的问题,实际上更恶心了:用户完全被剥夺了跨 phase 表达同一实体的抽象能力。
比如就想要精确表达 10 这个抽象的数,用 C++源码是做不到的。传统的 C/C++中,用户被迫在 pp-number 10 、integer-constant 10 作出抉择,而 C++加了一种介于两者之间的、光是语法上就明显更欠扁的 integral_constant<int, 10>,更加混乱(考虑到 template-template parameter 的无能,metafunction 不方便 partial application ,integral_constant 第一模板参数还特别不方便参数化地使用,更显得 int 这种“强类型”就是在没事找抽刷存在感)。
结果就算不考虑被静态类型污染的问题,真要通用,就得向上游迁移——及早确定然后顺下来给各个 phase 用(还照样省不掉显式“转换”),实际就意味逻辑就尽量塞预处理器了。这也就是一个整数,如果塞不进预处理器呢?
(想到 endianness 没法尽量只靠可移植的 template metaprogramming 实现最后还是得 std::endian 加 pp phase 层次的魔法这点,就气不打一处来。)
3 天前
回复了 fpure 创建的主题 程序员 这算不算是静态类型系统的缺憾
@codehz 既然都会加标记断言了,那为什么不更进一步,直接用 contract 而不是变着法子搞什么 refinement 得了(cf. Racket)?
到了这一步,这里真正麻烦到值得计较的反而是怎么确保 proper tail call 之类的更全局的性质,大部分类型论特性反而不重要了。
3 天前
回复了 fpure 创建的主题 程序员 这算不算是静态类型系统的缺憾
所有(静态)类型系统在遇到类型规则不符合需求时都会出现这类问题。越是如 Robert Harper 强调“静态”的正统性,遇到这个问题越会诛心。
这其实是大部分搞 PL 的都没搞清楚的实用通用语言设计中的核心问题(关键词:intrinsic and extrinsic views of typing )。相比来说,大部分 PL 壬所谓的 soundness 、totality 之类的问题,是很次要的。
根本解决方法是在基础设计中完全放弃带有静态类型系统的静态语言,让类型系统规则自身可编程。
作为魔改现有“无类型”动态语言发家的 TS ,恰恰是所有语言中这类问题最小的一类。不过即便是这样,要绕过去也基本意味着用户需要自己实现 JS 到 TS 的转换,因为 TS 的设计没有考虑到它自身这部分足够模块化而让便于用户复用(做成 JS 或 TS 的库),以节约重新实现类型系统的开销。
顺便,所谓 gradual typing 只是一种妥协,原则上并不确保用户可修改类型系统规则。
@Zerek +86:?
关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   918 人在线   最高记录 5497   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 13ms · UTC 20:59 · PVG 04:59 · LAX 13:59 · JFK 16:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.