首先，拿 Java/Kotlin 或者 Objective-C/Swift 这类语言互转来说明复杂程度不合理，因为它们在设计阶段的要点就是和前代语言充分兼容。这里是 Swift 社区关于实现和 C++互操作的设计理念文档： https://github.com/apple/swift/blob/main/docs/CppInteroperability/CppInteroperabilityManifesto.md ，感受一下这个长度。并且 (1) 这个文档还没完成；(2) Swift 和 C++的互操作因为 ABI 原因，仅限于和 Clang ，而 Swift 团队很多人也是 Clang 团队的成员；(3) 语言要素上 Swift 和 C++并没有差特别多。其他语言恐怕很难有这些条件吧？

其次，因为编程语言抽象层次各不相同，高抽象层次容易转换成低抽象层次，反过来就很难。比如一段合法的 C++代码，可能就没办法转成（ safe 的） Rust ，因为违反了生命期和所有权约定；操作内存的 C 代码也不太可能翻译到 JS.

如果想在尽量保留高级语言信息的前提下在语言之间做翻译（否则可以说都编译到汇编也算相互翻译），那可能需要每个语言都限制用到的特性，保留一个抽象相似的公共子集，类似 asm.js ，在这个层面做相互翻译比较现实。这么做依然需要相当大的投入，但收益却一般。想到的一个例子是 Eclipse 曾经将 C++写的 Clang 翻译成 Java ，以集成到项目里做 C/C++语法分析。

Watch 想降级或者重置非常麻烦，而且 watchOS 一般可以向上兼容新 iOS ，但反过来不一定，所以通常不推荐追 watchOS Beta

@valuable
认为 Lightning 好用和认为换成 USB-C 是好事不矛盾。我觉得 Lightning 接口本身很稳固，但出门多带一种线就很麻烦了。

1. UTF-8 是变长的，UTF-16 在有代理对的情况下也是变长的，得 UTF-32 才行

2. 即使考虑了变长情况，UTF-8/UTF-16 编码的一个「字符」还不是我们理解里的字符，emoji 这里尤其复杂：比如国旗🇨🇳实际上是由两个从 U+1F1E6 到 U+1F1FF 的特殊字符拼成的。

3. 如果要在显示的层面考虑「字符」（ glyph ）就更复杂了，因为几个可以单独存在的字符挨在一起时可以拼到一块，比如某些特殊语言或者 ligature

所以用 UTF-16 算是一个相对折中的方案，如果你不严格要求从第 390 万个「字符」开始，可以先跳到第 390 万个位置上，然后根据当前位置是 Higher/Lower Part 做调整

@ecnelises
另外我好奇楼主说的「往用户目录拉坨屎」指的是读写主目录的 Documents/Downloads/Photos 这些目录呢，还是在主目录~下面创建点开头的隐藏目录，或者是~/Library ？

1. 从之前和 Epic 打官司期间，苹果高管的言论来看，他们对 Mac 可以 side-loading 这个现实的态度，基本类似父母对待自己眼中不争气的孩子，躺平了。当然不排除他们真的在未来某个版本这么高，但鉴于只允许从 App Store 安装这个选项已经存在多年，而且真的要搞，Big Sur 那么好的机会没搞，可能就是没这个打算。

2. macOS 上有大量脚本程序、仅命令行的程序、用户自己编写的程序，这些怎么办？好，可以说允许用户自己签名，那跟现在不是没有区别了吗？ M1 上本来每个二进制可执行文件都要签名才能运行。

3. 现在发布一个 macOS 上用户可以直接打开的软件，你需要：一个 Apple Developer 订阅+用这个订阅相关的密钥签名+发到苹果服务器自动化跑一遍查毒 (notarize)，理论上如果一个软件出了大问题，苹果可以给所有 Mac 远程发指令撤销该开发者的签名以让其打不开。这个流程和 App Store 就差一个人工审查。

4. iOS 的封闭软件生态工作得很好是因为它从一开始就这么运行的。苹果迁移到 ARM 都快两年了还有很多软件没适配，短期内整个这个限制对 macOS 生态就是灾难。而且 iOS 不可控的下架行为已经让人意识到禁止 side-loading 就是有两面性的，禁止了对属于生产力设备的电脑伤害更大。

5. Mac App Store 限制本来就比 iOS App Store 松，JIT 权限也是放开的，Slack 等软件也是 Electron 做的，上架 MAS 一点问题没有。所以这些倒不是障碍。

GCC 的主要扩展 Clang 都支持，其余的 Clang 处在一个随缘状态：不保证一定支持，但你要实现也没什么人反对。

滥用编译器扩展的确会影响可移植性，但两害相权取其轻，GCC 扩展的可移植性比起内联汇编和各种指令集 /操作系统强相关的自带函数还是好多了。Mac 迁移到 ARM 算是在这方面敲醒了一些人。只要把这些特定编译器的扩展封到宏 /函数里，然后对不支持的编译器加上#error ，问题不大。

Sigh.. 网站把我 List 的缩进吞了。

然后在上面提到的统一数据库基础上，提供一套 CRUD 接口，每个应用对应一个私有子库，也可以通过认证获得其他库的权限。并且这套接口不只是服务端可以用，客户端也可以用（本地数据库），因为它更像是点对点之间的 sync 而不是全靠请求获得资料的 B-S 模式。

但在客户端，这样有一个问题：数据库对客户端而言非常大。我们可以按需下载那些 Blob 文件，并且不下载过往的操作日志，剩下的数据库不会很大，还可以辅以压缩。（ V2EX 全站的用户和贴子数据装 Sqlite 里应该也只有几个 G ）

有了这套协议，我们就可以实现真·前后端分离的系统了。说简单一点，就是在本地实现了一套类似 LeanCloud 的东西，前端和客户端只需要假设本地或服务器有这个模块，连同步都是由这套实现自动完成。

OP 在那个贴子里提到的存储在用户本地的信息集合，有些类似 Tim Berners Lee 搞的 Solid ( https://en.wikipedia.org/wiki/Solid_(web_decentralization_project) )？不过它更强调的是不同节点之间的互联。

---

有关同步的问题，我有过类似的想法：定义一种协议，它可以描述确定两个节点 A 和 B 之间的数据可以如何同步，并且

- A 和 B 不一定要相等，可以是 A 的子集和 B 的某个子集进行同步
- 比如 A 是一个人手机上的各种类型数据的集合，B 是一个服务器，那 A 只需要把照片这个子集和 B 里面属于 A 的部分同步
- 这个模式已经很常见了，但还没有发现有通用协议去规定它
- 同步当然要是增量的，但基于文件的同步不太靠谱，因为我们没法假定同步工具支持增量同步，也没法假定数据库到底是以何种方式存储的
- Event Sourcing 是个思路：每次修改会产生一条记录，当前数据是所有记录执行后的一个快照。这个设计类似 Flux 或者 Git ，所以很自然地，如果同步双方的记录日志分叉了，还可以尝试 merge
- 继续从 Git 思路出发，客户端和服务端是多对多关系，甚至没有服务端的概念，因为服务端本身也可以作为中继，同步到上游数据库
- 如何避免环出现呢？
- 不知道 OP 用不用 iCloud ，其实 iCloud 就像时刻连接着的一根线，把设备的数据和苹果的服务器做 iTunes 同步。这里同步的是数据库而不是文件（ iCloud 云盘是后来才有的），所以后来它们还开放了 CloudKit 这个东西
- 苹果的自带软件和若干第三方软件都偏好用 iTunes 风格的数据库而不是文件夹存数据。我喜欢这种方式，因为数据库比文件要结构化得多，能存更多元数据，读写同步效率也都更高
- 但并不是所有数据都能放到数据库里，比如很大的照片或录像，它们适合存放在单独的文件里作为 Blob. 如果把这些数据库和 Blob 打包并规范化（开发一个统一 API 操作），那会十分方便，并且可以和第一点提到的协议结合，软件的各个小数据库其实是系统大数据库的一部分（有点像 Windows 注册表了？）
- 某些文档数据库已经自带了管理 Blob 到文件的功能
- 由于数据结构高度统一，快照、备份、回滚这些功能都变得很容易，可以用类似 zfs send/receive 的方法轻松备份和加密

- 苹果公司标榜隐私是一种营销手段，但是营销不代表不做事。小米是不是标榜性价比？是。小米的性价比有没有代价？有。但小米依然有性价比。除了少数手机厂商，你很难看到互联网公司出来在隐私保护上内卷，打苹果的脸，这本身就能说明点问题了。
- 反对苹果的人最爱举的例子是 2014 年 iCloud 照片泄露事件以及和有关部门的合作（喷棱镜门的和喷云上贵州的建议先打一架），支持苹果的人最爱举的例子是 iOS 14.5 反广告追踪功能。但在楼上说的房间里的大象面前，这些事是否……太片面了些呢？举个例子，居民身份的数据泄露了，这恐怕比京东广告精不精准的负面影响高了几个数量级，但它和你用什么手机，有关系吗？
- 不要试图在网上和人就这些话题吵架：你说隐私保护，他说 iCloud 泄露，你说那是撞库，他开始复读一百块的布。

联想到了吗，对 HTTP 是否应该使用状态码来表达业务状态的争议，其实颇像「使用异常还是错误码」这个同样老生常谈的问题。有些人大小事都要抛异常；另一些人尝试 catch 一切异常，并永远使用错误码。而当代码要接入一个现有模块时，事情变得更复杂了。

HTTP 通用的错误码（ 4xx, 5xx ）很有限，就像系统定义的异常类型，必然无法涵盖所有错误的情况。但我们不必做二极管，始终在上面提到的两种人间反复横跳：尽管很多错误码是和 HTTP 协议强相关的（比如 411 ），至少常用的 401/403/404 语义可以完美对应项目中一定会出现的几种错误情况；除此之外，简单用 400 表达请求有问题，500 表达服务端有问题，搭配自定义的错误代码即可。

另一个和是否使用 HTTP 错误状态码相似的争议，是「是否要以 REST 方式组织 API 」。是的，生搬硬套的 CRUD 语义没办法定义现实中的所有复杂情况，但也不该因此就彻底抛弃这套被广泛接受的代码组织思路：GET 不应有副作用，PUT 相比 POST 有幂等性；实在不行把一些操作都抽象成某个 Action ，然后所有有副作用的操作一律 POST 也比一团乱麻来得整洁。

https://gist.github.com/ecnelises/c16af59384772e4548ac4e59e13b810f

稍微改了一个，不完美，可以加到自定义 CSS 里

也推荐一下我的 newsletter😁 https://weekly.love
上次在别人那里听到一个说法：给自己固定的时间写，时间结束就发稿，写多少是多少，这样能够缓解压力。

我猜不行，因为系统 API 甚至底层中断里就是把功能键和其他键的位分开的

我记得我上大学那会（ 2014 年）自己就突发奇想要买一台 Mac ，还悄悄找同学借了几千块。那会的 MacBook Pro 从做工、续航、性能等各个方面看都是顶尖，甚至买一台装 Windows 也不算脑抽的选择；并且当年的 OS X （还不叫 macOS ）远比今天稳定，用起来真的很舒服。

因为有些老师自己也用的 MacBook ，所以课程上一开始倒没有很多为难苹果用户的地方，不过听说隔壁专业编程课要用到 Windows 专有 API 。入学的时候没有很多人用 Mac ，到大二大三能慢慢发现很多同学开始又整了 Mac 当主力电脑，把原来的 Windows 做备用。其实 Intel Mac 好歹还能装个虚拟机，所以问题不大，M1 就相对麻烦。

总的来说还是推荐第一台电脑选个中规中矩的 Windows 就行，也不要拉得太满，毕竟等你了解更多以后可能想换电脑，而且现在性价比选择比以前还是更多了。毕竟这个专业实习赚钱也不算难，以后想玩 Mac 了再买一台也不迟（

https://github.com/ecnelises/awesome-wheels

之前有很多零零散散的想法，新开了个坑慢慢填，准备把收集的各种可以做的 Side Project 都拿来

小学时候某个乡土课本上写重庆的地图像什么，上面的人说像展翅的雄鹰。后来有个小测验有道题，问重庆地图像什么，我第一反应是之前看地图册留下的印象，像「人」字。结果老师说不对，应该像雄鹰。争执了好久，最后还是妥协了，不过自此以后深刻意识到有些权威就是傻 X

另外一个离谱的：小学卷子上问水滴石穿告诉我们什么道理，我写的「要珍惜时间」，因为站在石头的角度，总有被滴穿的那天……结果自然也是一个大叉