Forwarded from Solidot
计算机科学家在旅行商问题上取得突破
2020-10-10 15:23
当 Nathan Klein 开始读博时，他的两位导师提议共同研究理论计算机科学领域的一个著名难题。导师们认为，即使未能解决这个难题，在此过程中 Klein 将会学到很多东西。Klein 接受了，初生牛犊不怕虎，作为一年级的博士生，他并不知道会遇到多大的困难。Klein 和他在华盛顿大学的导师 Anna Karlin 和 Shayan Oveis Gharan 刚刚发表了一篇论文，报告了他们在困扰了计算机科学家近半个世纪的旅行商问题上取得的突破，找到了一种更好的方法去寻找近似解。
2020-10-10 15:23
当 Nathan Klein 开始读博时，他的两位导师提议共同研究理论计算机科学领域的一个著名难题。导师们认为，即使未能解决这个难题，在此过程中 Klein 将会学到很多东西。Klein 接受了，初生牛犊不怕虎，作为一年级的博士生，他并不知道会遇到多大的困难。Klein 和他在华盛顿大学的导师 Anna Karlin 和 Shayan Oveis Gharan 刚刚发表了一篇论文，报告了他们在困扰了计算机科学家近半个世纪的旅行商问题上取得的突破，找到了一种更好的方法去寻找近似解。
Forwarded from AlPlank (498633413)
Telegram
Sion's Channel
[Methods to prevent leaking website's origin server IP behind CDN]
As a beginner of the webmaster, you may know using CDN nodes to avoid leaking the original server's IP. Meanwhile, you would take some common measures, such as changing the domain hostname…
As a beginner of the webmaster, you may know using CDN nodes to avoid leaking the original server's IP. Meanwhile, you would take some common measures, such as changing the domain hostname…
Forwarded from Phonograph (Ralph 萌新喵)
Phonograph
在C语言里，你选择
#c #PLT 一般情况能用 condition 表达式还是不用常量 while+break/continue. （哪怕提前声名量或是用 do while ）
说要用的情况就是 main loop ，C 里没闭包就只能用函数指针，或者宏，不优雅不高效，只能选择 while(true) 。 当然是否
for(;;) 不喜欢，因为它本应是 for(init;cond;update) ，而 cond 在理论上省略默认 1 是不优雅的（这是语言设计上的不对）
原则上我是讨厌 1 替代 true 的，尽管对许多机器而言非0即真（不过说起来，所谓真假也就是控制流跳转与否而已）。
说要用的情况就是 main loop ，C 里没闭包就只能用函数指针，或者宏，不优雅不高效，只能选择 while(true) 。 当然是否
#define forever 也是看复用处有多少的。for(;;) 不喜欢，因为它本应是 for(init;cond;update) ，而 cond 在理论上省略默认 1 是不优雅的（这是语言设计上的不对）
原则上我是讨厌 1 替代 true 的，尽管对许多机器而言非0即真（不过说起来，所谓真假也就是控制流跳转与否而已）。
Forwarded from YSC 的频道
测试 HTTP Client 的 TLS 及 http/2 支持情况的几个网站:
https://www.howsmyssl.com/s/api.html (仅支持 TLS，能给出详细的信息)
https://cloudflare.com/cdn-cgi/trace (支持 TLS 和 http/2，只能给出支持的 TLS 版本，还有 IP 地址和 User-Agent)
https://http2.golang.org/ (仅支持 http/2)
https://www.howsmyssl.com/s/api.html (仅支持 TLS，能给出详细的信息)
https://cloudflare.com/cdn-cgi/trace (支持 TLS 和 http/2，只能给出支持的 TLS 版本，还有 IP 地址和 User-Agent)
https://http2.golang.org/ (仅支持 http/2)
#cs #PLT Expression Problem(Visitor Pattern, interpreter) 这个问题我也讲过 #zhihu https://zhuanlan.zhihu.com/p/163762783 ，你们可以比较一下。
知乎专栏
梗概Visitor Pattern
阅读这篇文章你应该理解小学数学，文中会用Java、Kotlin和Haskell三种编程语言，Haskell是附赠品不必理解。 一般来说函数式程序员对这个问题总结得也挺好，不过相信写的人本就少，写完后删了的人也挺多，这篇文章…
Forwarded from Solidot
旧代码和年长程序员难题
2020-10-13 15:29
今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的陈旧系统。建一条公路的费用可能远不及在这条公路的寿命期内的维护费用。在系统开发每投入 1 美元，那么在系统寿命期限内需要投入 8 到 10 美元去进行维护。一个软件系统的生命可能比设计者预想的要长得多。IT 预算的很大一部分是用于运营和维护而不是开发替代或进行现代化，这一比例越高，一个系统越不可能进行升级。
2020-10-13 15:29
今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的陈旧系统。建一条公路的费用可能远不及在这条公路的寿命期内的维护费用。在系统开发每投入 1 美元，那么在系统寿命期限内需要投入 8 到 10 美元去进行维护。一个软件系统的生命可能比设计者预想的要长得多。IT 预算的很大一部分是用于运营和维护而不是开发替代或进行现代化，这一比例越高，一个系统越不可能进行升级。
Solidot
旧代码和年长程序员难题 2020-10-13 15:29 今年初的新冠疫情带来的一个出人意料的结果是许多地方亟需 COBOL 程序员去维护历史悠久的旧代码。一个问题是陈旧软件陈旧代码的规模究竟有多大？以“Why Software Fails”一文著称的 Bob Charette 称，我们并不清楚这一问题的规模究竟有多大，我们所知道的是每年投入了数万亿美元去维护和运营这些系统，投入数千亿美元去进行现代化，而很多现代化项目都失败了。美国社会保障总署最近发布的报告承认他们也不清楚社会保障系统有多少是遗留的…
所以说，问题发现得越早，它所造成的麻烦就越小。看看这个语言、现在语言工具创作者的态度，带来了多少麻烦。 #PLT #cs #statement
还有，程序员要明白自己是怎么工作的，懂得如何减小机械化的工作，编译原理/元编程/代码生成 是最好的选择
定义式的程序设计完全不存在这种弱智问题，它本身是语言无关、平台无关的，纯编译期的东西，就像响应式的 Web 一样，何必操心程序在哪用呢。
如果你想设计迁移翻译器，也就比实现两个 parser + 1 decompiler 要容易一点点，真是何苦呢？写死了用不活，带来额外的麻烦。
基础程序结构、数据结构就那么多，若判对重复、组行表集合，编程最根本的区别在于范式和底层访问性，才不是什么语法什么封装，而主流的范式就是过程式，有些人明白怎么编程，却不重视怎么平衡费益、解决问题。
解决一个问题，不在未来给别人带来更多问题，这才是程序设计的道理，即便这样何尝容易实现过呢。
还有，程序员要明白自己是怎么工作的，懂得如何减小机械化的工作，编译原理/元编程/代码生成 是最好的选择
定义式的程序设计完全不存在这种弱智问题，它本身是语言无关、平台无关的，纯编译期的东西，就像响应式的 Web 一样，何必操心程序在哪用呢。
如果你想设计迁移翻译器，也就比实现两个 parser + 1 decompiler 要容易一点点，真是何苦呢？写死了用不活，带来额外的麻烦。
基础程序结构、数据结构就那么多，若判对重复、组行表集合，编程最根本的区别在于范式和底层访问性，才不是什么语法什么封装，而主流的范式就是过程式，有些人明白怎么编程，却不重视怎么平衡费益、解决问题。
解决一个问题，不在未来给别人带来更多问题，这才是程序设计的道理，即便这样何尝容易实现过呢。
#PLT 绝句 最近的变更：
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
决定移除『扩物』，从此简记法是「储例况标内抽象」
原因有二：
从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理
从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了）
而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义
决定将 抽象/开放/终定 变为 待定/再定/终定 ，『抽象性/覆写性』为『确定性』
对应 abstract/open/final
TODO() 则是 待写()
从兼容性上， open 也可视为可见性修饰符，语义匮乏，没必要移植到中文
现在，只有 储例况标内
expect/actual 仍 待例/实际
可见性： 公开 族内 私下 内部
覆写性： 开放 终定 抽象 实现
特殊：隐式 记法
内联 不联
待例 实际
晚成 尾递归 断续
duangsuse::Echo
#PLT 绝句 最近的变更： 决定移除『扩物』，从此简记法是「储例况标内抽象」 原因有二： 从编程惯用来看，会连续创建多个 receiver 类型不同的 ext fun/val ，扩物的写法有悖常理 从语言一致性来看， Kotlin 的 receiver/param1 互化带来的 fun(type) with receiver 与「扩物」不对仗（关于知识网的联系就换成所有 fun/val 都隐式于『我类型』好了） 而且即便标物和抽象物也都是『物』，可扩物实际上只是种蹩脚的编译元数据定义 决定将 抽象/开放/终定…
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
visibility/可见性:
公开 族内 私下 内部
public protected private internal
rewritability/确定性:
待定 再定 终定 实现
abstract open final override
construct/构件:
包 类型别名 常量 类 物 例 造于 事 量/变
package typealias const-val interface class object constructor fun val/var
package typealias const class thing insta constructor fun val/var
affairs/杂件:
取者 置者 代者 恒事 性质推导
get set by
class kinds/类定义的种类:
储 例 况 标 内 待定
data enum sealed annotation inner abstract
multitarget/多平台:
待例 实际
expect actual
others/其它:
晚成 尾递归 断续 隐式 记法
lateinit tailrec suspend implicit notation
内联 不联
inline noinline
access/访问:
(o的n) (o去v) (o[k]) (k存于o)
(o.n) o.v() o[k] (k in o)
type RHS/类型:
属于 作成 试作
is as as?
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
所以大家可以看到，表达用的语言，对编程语言的模样是有影响的。 试问按英文设计能弄出 待定/再定/终定 的区别吗？恐怕很鸡肋，甚至不如 abstract/open/final
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
顺便，命名风格和参数顺序对结果可读性也会有影响，它们也会间接影响到 API 的设计。
duangsuse::Echo
绝句的面向对象架构现在已经和 Java 面向对象，乃至 Kotlin 的正统 OOP 都有点差异了 visibility/可见性: 公开 族内 私下 内部 public protected private internal rewritability/确定性: 待定 再定 终定 实现 abstract open final override construct/构件: 包 类型别名 常量 类 物 例 造于 事 量/变 package typealias const-val interface class…
#dev #design 在这里谈下自己对 「待定/再定/终定」 新写法的看法吧。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。
加了这个以后我一直觉得很难受（一部分也是我在考虑无GC的『存储』子类如何实现），因为某种意义上这是在否定过去的设计“特性”——绝句在这方面之前和 Kotlin 不一样，我试着把『抽象性』隔离了出来（作为 抽象物 这个关键字），然后 open 和 final 保持不变（因为 abstract class 几乎是一个惯例，有理由为其分配关键字）
从用法上看， final 只在指定 open class 里不可再定的成员时才使用，频率最少；open 的频率在其次，另外如果要减轻
interface X { abstract val a:Int } 这种不优雅的有效语法对程序明确性的影响，我觉得不应该沿用老名称。新名称也是符合绝句设计惯例的——待定/再定/终定 对毫无编程经验的人也容易理解（日常用语），并且一定程度隐含了底层方法解析确定性的语义。
可是现在又改回来了——
抽象物『标物处理器』为
待定的物『标物处理器』为
再定的物『活动』为
为了这三个“X定”的一致性，是不可能再弄『待定物』这样的关键字的，而目前就打回原形、和 Kotlin 一样，真的很不爽啊（最讨厌设计得和别人一样了，但我不得不承认这是最好的做法）。
说白了我就是不想否定之前设计的有效性……（当然它也带来了 抽象/实现(override) 的这个配对）
关于面向对象 继承、抽象、多态 三特性绝句到底什么该抄，什么该再定，以前也是真的没好好想过（单纯觉得怎么方便怎么弄了），一直在探索而已。 😓
关于面向对象 继承、抽象、多态 三特性绝句到底什么该抄，什么该再定，以前也是真的没好好想过（单纯觉得怎么方便怎么弄了），一直在探索而已。 😓