E-- 是一种旨在将大语言模型（LLM）的创造性灵活性与确定性代码的可靠性相结合的编程语言。它采用两阶段流水线：首先是一个可选的、由大模型驱动的“标准化器”，将自由格式的英语转换为标准格式；随后是一个严格的确定性解析器，将该标准代码转译为标准的 Python 代码。 主要特性包括： * **确定性执行：** 一旦代码进入“标准 E--”格式，大模型便不再参与运行。生成的 Python 代码纯粹、可复现且易于调试。 * **大模型集成：** 用户可以插入 `{{ ... }}` 插槽，由大模型生成特定的值或代码片段。这些内容在转译时仅解析一次并进行缓存，确保后续构建在离线状态下也能保持确定性。 * **安全与透明：** E-- 使用明确的分隔符（如函数调用使用的 `[[ ]]`）来消除歧义。由于编译器是标准的非概率性编译器，生成的 Python 代码简洁且不受特定项目许可证的限制。 E-- 非常适合希望通过自然语言编写代码，同时又不愿牺牲传统确定性软件稳定性、可审计性和速度的开发者。它是开源的，可嵌入，并可通过 PyPI 获取。
每日HackerNews RSS
Show HN: E-- – 一种介于英语和 Python 之间的编程语言 Show HN: E-- – A language you dial between English and Python
2 天前
“E--” 是一种新的实验性编程语言，旨在填补自然语言与 Python 之间的鸿沟。该语言由 OdedF 开发，允许开发者“调节”英语与 Python 的混合比例：利用基于英语的大语言模型（LLM）处理槽位来实现描述性逻辑，同时将底层结构保留在确定性且经过缓存的 Python 代码中。
该项目在 Hacker News 上引发了微妙的讨论。一些用户欣赏这种实验性方法——特别是针对音乐家或设计师等领域专家——但其他人则持怀疑态度。批评者指出，E-- 实际上只是一种新的领域特定语言（DSL），而非真正的英语，并质疑“英语优先”编程的有效性。怀疑论者认为，核心挑战依然是“软件素养”的匮乏；无论语法如何，非程序员可能仍难以准确定义逻辑。此外，一些社区成员还指出了该名称与历史上“E”编程语言潜在的命名冲突。
尽管存在这些担忧，开发者仍将 E-- 视为一种赋能工具，旨在让领域专家能够编写代码，即使这最终会将行业导向使用大语言模型来生成全面文档，而非直接生成可执行代码。
SQLite 允许在字符串值中包含 NUL 字符（`0x00`），但这可能会导致误导性的行为。标准的函数（如 `length()` 和 `quote()`）以及命令行界面（CLI）会在遇到第一个 NUL 字符时截断输出。这会造成一种差异：数据库确实完整存储了字符串，但查询结果和 CLI 显示可能会错误地暗示字符串已提前结束。 若要验证包含 NUL 字符的字符串的真实长度和内容，应将该值转换为 `BLOB`。若要识别受到嵌入 NUL 字符影响的行，请使用 `instr(b, char(0))` 函数。如果需要清理数据，可以使用带有 `substr()` 的 `UPDATE` 语句来移除 NUL 字符及其后的内容。 由于 NUL 字符可能导致混淆和工具不兼容，因此不建议在 SQLite 文本字符串中使用 NUL 字符。
近期的一场 Hacker News 讨论指出，SQLite 在处理字符串中的 NUL 字符时存在局限性。许多核心函数（包括 `length()`、`quote()` 以及命令行工具的 `.dump` 命令）在遇到 NUL 字节时会截断数据。
批评者认为，这种行为源于对 C 语言风格字符串处理的延续，即 NUL 被视为字符串终止符。虽然一些参与者建议用户应将任意二进制数据存储为 `BLOB` 类型以规避这些问题，但另一些人指出，为了恢复功能而将其转换为文本类型往往会再次导致相同的数据丢失问题。此次讨论凸显了遗留架构决策与确保数据完整性需求之间的矛盾；一些人建议，数据库应在遇到 NUL 字符时发出警告并截断数据，或者在插入时直接拒绝包含 NUL 字符的数据，以防止出现不可预期的行为。
请提供您需要翻译的内容。
抱歉。
在 1996 年的文章《反 Mac 界面》（The Anti-Mac Interface）中，唐·根特纳（Don Gentner）与雅各布·尼尔森（Jakob Nielsen）通过质疑麦金塔（Macintosh）人机界面指南的基本原则，挑战了 WIMP（窗口、图标、菜单、指针）模式的统治地位。作者在承认 Mac 使计算变得易于新手上手的同时，也指出这些设计限制——如僵化的隐喻、直接操纵和完全的用户控制——束缚了创新，并阻碍了资深用户的效率。
为了超越这种“停滞”的范式，作者提出了一个专为网络化、专家驱动的未来而设计的“反 Mac”界面。该模型倾向于使用语言交互（描述与命令）而非单纯的指向操作，偏好深层的面向对象表示而非静态图标，并主张在用户与智能代理之间共享控制权。通过摒弃对持续、显式用户输入及“感知稳定性”的必要性，他们构想了一个计算机会主动充当合作伙伴的界面。
归根结底，作者并非主张敌视或抛弃图形界面，而是将其作为一种激发全新设计范式的理论练习。他们认为，随着计算能力和用户专业知识的增长，界面必须从“模仿办公室”演变为能够利用语言、自动化以及丰富分布式数据环境的系统。
这篇 Hacker News 讨论回顾了 1996 年的文章《反 Mac 用户界面》（The Anti-Mac User Interface），该文探讨了计算机领域中视觉化“所见即所得”界面与基于语言的控制方式之间的矛盾。
用户们分享了关于 Sony Magic Cap 等充斥着隐喻的失败界面的轶事，批评它们是笨拙的“冒险游戏”式环境，为了风格而牺牲了易用性。相反，评论者指出，现代大型语言模型（LLM）和智能体已经实现了该文长久以来的预言：即转向使用自然语言来指挥复杂系统。
这场对话凸显了计算领域中一个持续存在的权衡：虽然从编译器到 AI 智能体等各层抽象提供了便利性和可访问性，但往往以牺牲精细控制能力为代价。许多参与者认为，现代计算趋势（如简化的操作系统界面和 AI 驱动的自动化）证实了作者最初的担忧，即用户为了追求轻松而逐渐放弃了控制权。最终，该讨论认为，在直接操作与基于语言的脚本式控制之间切换的能力是现代开发者的一种“超能力”，同时也指出，向 LLM 发送指令本身就是一种新型的专业编程形式。
客户端挑战：您的浏览器已禁用 JavaScript。请启用 JavaScript 以继续。本网站的一个必要组件无法加载。这可能是由于浏览器扩展、网络问题或浏览器设置所致。请检查您的连接、禁用任何广告拦截器，或尝试使用其他浏览器。
这篇 Hacker News 的讨论重新审视了一篇 2018 年关于金属有机框架材料（MOFs）的文章，该材料曾因在催化和化学转化方面的潜力而被誉为“奇迹材料”。
随着 2025 年 MOF 先驱奥马尔·亚基（Omar M. Yaghi）被授予诺贝尔化学奖，相关讨论再度兴起。参与者在探讨 MOF 在甲烷转化和自旋电子学等领域的技术前景时指出，考虑到该领域起源于 20 世纪 90 年代，“新”这一概念是相对的。
讨论中很大一部分篇幅聚焦于学术环境，特别提到了亚基近期转任中国清华大学一事。此举引发了用户关于美国科研经费现状的争论，人们担心国内研究支持的萎缩，加上更广泛的政治和体制挑战，可能会威胁到美国在科技创新领域的长期领先地位。尽管在这些地缘政治影响上观点不一，但大家普遍认同 MOF 作为未来技术基础材料所具备的变革潜力。
作者分享了使用大语言模型（如 Claude）配置 MikroTik 网络硬件的积极经验。虽然网络技术本身很复杂，MikroTik 的界面也令人望而生畏，但作者认为大语言模型是一种“混乱的增效剂”，能够加速新旧网络的设置过程。 利用大语言模型进行网络配置的关键心得如下： * **工作流程：** 使用 REST/JSON API 而非 SSH，以避免文本解析错误；同时利用 MAC-Telnet，以便在 IP 配置失效时保持连接。 * **最佳实践：** 务必对大语言模型进行严格管控，通过增量测试来应用更改，频繁导出配置以进行版本控制，并使用多个模型对命令进行交叉验证。 * **效率：** 使用 CAPsMAN 等工具简化 Wi-Fi 管理，同时维护恢复手册和标准化的命名规范，这对长期稳定性至关重要。 * **警告：** 切勿认为大语言模型生成的代码绝对正确；模型会产生幻觉，因此对照当前 RouterOS 版本验证语法，并在每一步操作后进行测试至关重要。 总之，作者鼓励采用实验性的方法：拥抱大语言模型来处理复杂任务，但必须保持严谨的验证，以确保网络稳健且功能正常。
Hacker News 的讨论强调了大型语言模型（LLM）正成为网络配置与管理的强大工具，特别是在 MikroTik 设备方面。
主要内容包括：
* **文档改进**：MikroTik 已从传统的 Confluence Wiki 转向基于 Docusaurus 的站点，使其文档对 AI 更加友好。用户可以在 URL 后添加 `.md` 以提取简洁、适用于 LLM 的 Markdown 内容。
* **工作流效率**：许多用户利用 LLM 生成幂等配置脚本，或协助排查 VLAN 和路由等复杂的网络概念。这种方法取代了以往的“复制粘贴”，实现了文档化且可复现的脚本编写。
* **运维效益**：支持者认为，除了简单的配置，AI 在处理海量遥测数据进行网络分类（Triage）以及自动化执行以往积压的编排任务方面表现出色。
* **安全与最佳实践**：一个反复出现的主题是共享配置时需保持谨慎。用户强调在处理前应清除敏感凭据，或运行本地模型以维护隐私。
* **工具**：讨论中提到了使用 Terraform 提供程序进行状态管理，尽管一些用户认为原始脚本在处理配置偏移时更具灵活性。
总体而言，虽然这些工具降低了复杂设置的准入门槛，但用户强调，扎实的网络基础知识对于测试和验证仍然至关重要。
SQLite 是一个功能强大且符合行业标准的数据库引擎，但作者认为其默认配置存在问题。主要问题包括： 1. **外键被禁用**：SQLite 默认忽略引用完整性，这存在产生“悬空引用”和数据损坏的风险。 2. **类型宽松**：列允许存储与其定义不一致的数据类型，导致意外行为。虽然“严格”表可以解决此问题，但必须针对每个表单独启用。 3. **忙碌错误（Busy errors）**：当遇到并发写锁时，SQLite 会立即报错而不是等待，这会导致多进程环境下的崩溃。 4. **性能未达最优**：预写日志（WAL）等关键功能默认处于禁用状态，从而阻碍了写入速度。 为了在不破坏向后兼容性的前提下解决这些问题，作者提出了受 Rust 启发的“版本（Editions）”系统。通过实现类似 `PRAGMA edition = 2026;` 的命令，用户可以选择启用一套现代、安全且性能更优的默认设置。这种方法既能让引擎不断进化，又能确保遗留应用程序的稳定性。作者建议，这个“超级编译指示（super pragma）”应强制要求开启外键、启用 `busy_timeout` 和 WAL 模式，并实现严格类型标准化。
近期 Hacker News 上的一场讨论探讨了一项提案：建议 SQLite 引入类似于 Rust 编程语言的“版本（editions）”机制，以便在不破坏向后兼容性的前提下，实现默认行为的现代化。
作者认为，许多专业的 SQLite 用户通常会采用一套相同的“合理”配置（例如启用外键约束、使用 `STRICT` 表以及设置 `busy_timeout`），而这些配置往往与 SQLite 当前的默认设置不同。通过实施“版本”机制，开发者只需通过简单的命令（如 `PRAGMA edition = 2026`），即可为新项目启用这些现代化的默认设置，从而避免手动重复配置。
该提案引发了激烈的争论：
* **支持者**认为，这是一种在不影响现有稳定数据库文件的前提下，演进软件并摆脱历史技术债务的简洁方式。
* **质疑者**则认为，SQLite 的成功源于其简洁性以及对向后兼容性的严格遵循。许多人担心引入版本机制会导致生态碎片化、增加维护复杂度，或引发关于文件格式兼容性的混淆。
尽管有人提出了其他替代方案，例如改进文档、使用配置文件或外部封装，但此次讨论突显出用户群体之间存在明显的观点分歧：一方希望拥有更现代的安全默认设置，而另一方则更推崇 SQLite 目前稳定一致的设计理念。
抱歉。
这份列表涵盖了多种全球语言，从英语、西班牙语、法语和中文等主要国际语言，到巴斯克语、卡纳达语以及各种斯拉夫和斯堪的纳维亚方言等区域性和专业性语言。它展示了广泛的语言代表性，并包含了原始文字及其对应的英语名称。
我们所使用的字母并非单纯的抽象符号；它们是人类数千年演进的结晶。从古老的牛头状“aleph”到源于笔触技法的罗马衬线，我们的字体设计深植于人类经验的现实之中——源于我们的手腕、我们的工具以及我们的历史。 相比之下，生成式人工智能缺乏这种生活体验。它基于现有数据运作，提供了一种顺滑的捷径，所产出的只是“皮影戏”而非真正的人类创新。过度依赖人工智能，我们有将视觉文化僵化的风险，使那些未被充分代表的语言和文化被困在只有人类设计师才能开启的门后。 真正的创新需要创作过程中的磨砺。作为一名字体设计师，我认为排版设计的未来不应是对过去的重混，而应是对不断变化的世界的演进式表达。由于人工智能无法进行发明、无法感知关怀、也无法理解作品的文化意义，它只会导向一片贫瘠的创意荒原。我的字库拒绝使用人工智能，转而选择尊重人类工艺的传承。我们的作品过去、现在乃至未来，都将始终由人类之手创作。
抱歉。