对 xxx 的希望
大约 7 分钟
对 xxx 的希望
你可以从此处看到我的事物观念。
查看政治性内容请前往愿景。
对移动端剪贴板的希望
桌面端剪贴板有 ditto
无论是国内输入法的长时间保存剪贴板，还是谷歌输入法的一小时后删除的剪贴板，都有其取舍与不便之处。我选择折中说——
- 剪贴板数据永久保存仅文本数据，可手动访问，而应用对剪贴板的访问通过条数来限制。（例：仅能访问最近一条）
对浏览器的希望
- 原生支持 ts when
- 参考一下人家 Arc 的设计理念
对编程语言的希望
- 完整的 oop (class + interface / trait)
- interface / trait 提供了自由组合，在泛型中具有极为强大的作用。只依赖虚函数继承的纯 class 不够完备。
- 充分的内置数据类型 (dict, tree and map)
- 清晰的所有权机制 (rust,
我们不要学 c++)- 并且可以选择是否使用 gc (
import gc)
- 并且可以选择是否使用 gc (
- 完善的包管理与二进制编译 (cargo, minimize release bin)
- 提供最高的自由度 (可以直接操作 pointer)
- 所有错误均为可恢复错误 (python)
例如，linux rust 内核尽量避免 panic
尽可能减少 undefined behaviour。ub 可以增加性能
通过 io 暂存变量便捷的 serialization 支持- 高度模块化
- 支持对函数式编程的优化，例如热更新 (hot-reloading)
- 区别函数 (function) 与闭包 (closure)，推荐使用链式调用
- 自由选择静态类型与动态类型 (ts, any)
- 充足的语法糖 (js, kt)
可能算是各语言优点的融合怪。。不过确实不是很现实捏~
对算法竞赛 & OJ contest 的希望
- 支持所有主流语言的所有主要版本。（主流语言至少得包括 15 个吧，版本得支持最新标准，C++ 得支持多编译器吧）
- 提交后即时出结果。（I love IOI，这个是根据赛制决定的。然而我不喜欢非实时的赛制。）
- 样例必需具有典型性与足够的数量级。
（出题人，您也不想您的母亲被人问候吧，） - 需要对至少不止一个样例作出样例解释。
- 提供快读模版，否则请留出充足的 io 时间。
- 检查点不包含样例数据。
- 对于 online 的非正式比赛，在任何时候（赛前、中、后）都应能够参加比赛做题。
对聊天软件/协议的希望
用了一堆聊天软件，脑子里已经有了许多清晰的认知。
首先这里解释一些概念：
Organization(org)：最基本的管理单位
会话：Organization 下属的一个管理单位，可以是 simple processer multiple comsumer（频道/公告），oneshot（私聊），mpmc（群组）等。
基础设置都分为：全局设置，org 内设置，会话内设置。
分组！打 tag！
- 分组是一种抽象，但是细分不能层次超过两层，即用户最多点击两次就能进入任何会话。目前的聊天软件基本都如此设计。
- 以 Organization 为核心，单个 org 内能够创建不同的会话，并进行细致的权限管理。
- 普通成员可以在 org 中创建任意个私密会话，并加入 org 中的成员，私密会话对未加入成员不可见。也就是将所谓的“拉小群”功能集成到 org 本身。
多取一功能：对 org 内的一部分人@，而其中的任一一人回复，就会取消这个@对其他人的高亮提醒。
能够创建单条消息引用链接和多条。
需要完美的上下文定位功能。（这点现有聊天软件都做的很差）
支持较好的全局搜索功能（CJK）。
永久云端保存文本聊天记录，本机保存媒体。
- 或者，静态文件以 hash 标识，唯一来源激励，人工响应判重系统，有效转发延时。
支持类正则式 pattern 屏蔽，按成员屏蔽。
完整地支持 markdown。（telegram 差了点）
支持自定义排版样式，html 或自定义排版语言。
设置是否允许其他人看到已读状态
提供 bot api
端到端加密压缩，节省存储空间与流量
- org 内分发公钥
对推荐算法的希望
——如果人无法控制自己的喜好，那么这个推荐算法还是赶紧死掉比较好。
点名B 站。
- 开源透明，任何人可管理自己的喜好。
- 提供喜好管理面板，可随时添加或删除。
- 算法以 tag 而不是某一类型视频作为推荐依据。
- 在面对一个被推荐的 tag 时，用户可选择：
- 封禁此 tag 半年 / 一个月 / 永久
- 减少此 tag 出现频率半年 / 一个月 / 永久
- 增加此 tag 推荐频率半年 / 一个月 / 永久
- 大幅增加此 tag 推荐频率 15 天
对翻译协作平台的希望
翻译平台我只用过 Crowdin 和 WEBLATE，当时已经有了一些想法。最近我和 Asuka Minato 被 GitLocalize 恶心到了[1]，于是我开始深入思考一个好的翻译平台需要做到哪些东西。
- 接入机翻预翻译支持，人工润色，可以轻松很多。
- 机翻本身质量不要太差。Google, deepl 都行，其他的得具体分析。
- Crowdin 的机翻就不太够。
- 细粒度的协作，特别是志愿翻译更需要做到这一点。能够将翻译精确到句子，即可以只翻译这一句话，而不是整个文档。通过分散目标，能够充分调动译者的积极性，并且容易让更多的人参与。
- 我本来是想为某项目翻两句的，然而它用的 GitLocalize 不支持细粒度，导致我没有动力而直接放弃。（毕竟是个我自己都不用的项目）
- 对他人的翻译做出修改与评价（评分）。
- 对于大众翻译，译者的水平不尽相同。
- 在不同场景下有不同的翻译需求。文档一般没有太多翻译空间，但是对于文学作品来说，听取不同的翻译意见是很重要的。
- 评价当然也需要是细粒度的（针对某句翻译评价）。
- 统一专有名词与关键词的译法。
- 我最近在看的 Re0 文库版，里面的人名都不统一。特别是前面译
巴鲁斯，后面直接变成864，我真的没绷住，太野鸡了
- 我最近在看的 Re0 文库版，里面的人名都不统一。特别是前面译
- 容易与项目集成/接入。这是开发者要考虑的选项，也是一个翻译平台被选择的大前提。如果为了 i18n 而要手动将文档内容（例如 md）转成平台的支持格式（例如 yaml 或 binary），我肯定会觉得痛苦然后放弃的。
- 翻译内容安全性。由于内容全部存在云上，这对云服务商提出了一些要求（实际上也是最基本的需求）。反应速度先不说，至少翻译的东西不能丢吧。
- 记得本地留备份。[2]
——
对 RSS 阅读器的希望
- 不要太大，不要 electron 那样内置浏览器。
- 具有浏览器扩展或者类似功能，可以选中网页元素，自动推断订阅源。例如 RSSHub 和 ireader。
- 订阅源分组/分 tag，高维度控制。
- 集成社交媒体的 bot（例：telegram），可以通过其发送 RSS 消息。
- 自动 AI 总结。
——