编程与软件工程nibblestew.blogspot.com
编程语言的关键不在它做什么，而在它引导你做什么
It's not what programming languages do, it's what they shepherd you to
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇博文提出：编程语言的价值不在于它能做什么，而在于它引导（shepherd）你写出什么样的代码。语言通过类型系统、默认风格等设计选择，把程序员推向某些习惯、远离另一些习惯，这些“引导”比功能列表更能决定代码质量。
为什么经久不衰：它把“语言塑造习惯”这一常见争论提炼成一个清晰的分析框架，多年后讨论 Rust、Go、Haskell 的设计取舍时依然适用。
HN 评论精选
用 Haskell、Rust、Go、C# 的对比具体说明语言如何通过设计引导好习惯或纵容坏习惯
这就是人们说 Haskell“有主见”的意思。Haskell 强迫你把 IO 代码和库代码分离，任何含 IO 操作的函数都会污染返回值；参数化多态是默认，引导你写通用代码。它充满这类“不允许你写不正确代码”的小决定，哪怕这意味着和编译器搏斗。Rust 把这套哲学用在指针上：每个值都有生命周期和所有权，很难写出内存不安全的代码。Rust 和 Haskell 都把可能失败的值包进小盒子里，取出来就必须检查类型；而 C# 里没人阻止你返回 null 还不告诉任何人。Haskell 的哲学是“让无效的代码无法被表示”。写 Go 的人喜欢并发简单、gofmt 强制统一风格——把这些东西内建进语言本身。
c3534l查看英文原文
This is what people mean when they say Haskell is "opinionated." Haskell shepherds you into separating out IO code from library code to such an extent that literally any function that has an IO action taints the value returned from that function, causing it to be an IO value, and trying to pass that IO value into another function makes the return type of that function IO, too. Parametric polymorphism is the default, too, so it also shepherds you into writing general purpose code. Haskell is full of these little decisions where it just won't let you do something because it's not "correct" code, and they kind of don't care if that makes coding in it a fight against the compiler. Rust took that philosophy and applied it pointers. Every value has a lifetime and an ownership which makes it quite hard to do things that aren't memory safe. Both Rust and Haskell wrap values that can fail in little boxes, and to get them out you have to check which type of value it is, and in C# there's nothing stopping you from returning null and not telling anyone that you can return null, and just assuming people will check for null all the time. Haskell has a philosophy of "make invalid code unrepresentable." The concept of a value being in a box, rather than null being a possible value makes it impossible to use that value without getting it out. People who write Go love that concurrency is easy and Go fmt has enforced a single canonical style. Building these sorts of things into the language goes a long way in getting them adopted and becoming the norm. I think we saw a rise of the easy, anything-goes, screw-performance scripting languages. I think the next fashion seems to be in enforcing "correct" coding style. They all have their place.
以多年 C++ 大型代码库经验佐证：语言养成的坏习惯即使团队自律也难以避免
这是我对 C++ 的主要不满。我的工作曾是让游戏引擎代码库跑起来并集成工具，见过大量大型 C++ 代码库，几乎每个都有同样的坏毛病：海量全局变量、在代码里配置构建选项、让人搞不清类到底需要什么代码的头文件迷宫。后来我参与开发一个较新的 C++ 代码库，同事们很愿意写可维护的代码、遵守规范，但保持头文件卫生依然极其困难。多年来我拒绝说任何语言好或坏，坚持“用合适的工具”，但 C++ 的缺陷与它的用途无关，主要源于对向后兼容的执着——即使在它该用的场景下也漏洞百出。我现在基本认为它是一门糟糕的语言。
DubiousPusher查看英文原文
This is my main issue with C++. For a while my job was to get game engine codebases running, integrate tools and move on. So I saw a lot of big C++ codebases. Nearly every one had the same bad behaviors. Tons of globals. Configuring build options from code. Header mazes that made it clear people didn't actually know what code their classes needed. I then worked for awhile developing a fairly fresh C++ code base. The programers I worked with were very willing to write maintainable code and follow a standard and it was still really damn hard to keep things like header hygene. When I go back to the language I can't believe how much time I spend dealing with minor issues that stem from the bad habits it builds. For years I would refuse to say any language was good or bad. Always I insisted you use the right tool for the job. And there are some features of C++ that when you need them you have to use that language or maybe C in its place. But the shortcomings are unrelated to language's issues which largely seem to come from a focus on backward comparability. And so even used in its right application it seems incredibly flawed. And I pretty much believe it's a bad language now. Disclaimer: I learned to program with C++, I understand its power and for years I loved the language. I also understand there are situations where despite its shortcomings it is the right choice.
把“引导”概念扩展到更多语言和工具，说明这是普遍的设计现象
这是语言坏味道的绝佳比喻！更多例子：Python 引导你用列表推导式，即使那几乎总是过早优化且比循环难读；Bash 引导你用 ls、反引号、无用的 cat、把所有文本当 ASCII；Lisp 引导你造自己的语言。工具也在引导：IDEA 引导你随时重构，Firefox 引导你装隐私扩展，Chrome 引导你用 Google 扩展，非 Mac 的 *nix 引导你用 shell 并默认不信任软件，Windows 和 Mac 则引导你凡事用 GUI 并默认信任软件。
l0b0查看英文原文
That's a great metaphor for language smells! Some more anecdotes: - Python shepherds you into using list comprehensions, even when it's almost always premature optimization and much harder to read than a loop. As a language smell that's not bad, it's just the worst I could think of in a post-v2 world. Luckily there's `black`, `flake8`, `isort` and `mypy`. - Bash shepherds you into using `ls` and backticks, useless `cat`s, treating all text as ASCII, and premature portability in the form of "POSIX-ish". Luckily `shellcheck` takes care of several common issues. - Lisp shepherds you into building your own language. There's also tool shepherding: - IDEA shepherds you into refactoring all the time, since it's the only IDE which does this anywhere near reliably enough. (At least in Java. In other languages renaming something with a common name is almost guaranteed to also rename unrelated stuff.) - Firefox shepherds you into using privacy extensions. - Chrome shepherds you into using Google extensions. - Android shepherds you into installing shedloads of apps you hardly ever use. - *nixes other than Mac OS shepherd you into using the shell and distrusting software by default. - Windows and Mac OS shepherd you into using GUIs for everything and trusting software by default.
反驳：真正塑造代码习惯的是语言社区的文化和权威，而非语言本身
别被“是语言让我这么干”骗了——往往是语言周边的文化让你这么干。不同技术有由常常自封的领袖人物（甚至是匿名的）带来的文化，这些领袖可以说服他人某种滥用是“既定文化规范”，从而将其流行化。第三方框架常被用来确立领袖地位和滥用实践；一旦站稳脚跟，就成了“框架让我这么干”。旁观者看到的共识是“你的语言真烂”，而他们乐于强化这种印象，因为他们正忙着建立自己竞争性的文化和领袖地位。
kerblang查看英文原文
Do not be fooled into thinking, "The language made me do it" when the culture that surrounds the language made you do it. Different technologies have cultures brought on by often self-appointed leadership figures, even anonymous ones. Those leadership figures can popularize abuse by convincing others that it's a well-established cultural norm, simply because we tend to loathe non-conformity. Third-party frameworks are often used to establish one's self as a leader and establish abusive practices. Once the foothold is firm, it becomes literally "The framework made me do it." Cultural norms mandate the framework, and the framework forces the abuse. If anyone protests about the consequences of abuse, blame is redirected back at the language. To any onlooker, the consensus seems clear: Your language sucks! Those same onlookers are happy to reinforce this perception because they are busy trying to establish competing cultures & leaders of their own. "You should try my language!" Of course their primary goal is not to help, but to improve their own status by rising the tide and lifting their own boat. If they wanted to really help, they would work on establishing better culture instead of jockeying for popular culture.
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选