职业与工作方法coding.derkeiler.com
懂 Lisp 如何毁了我的编程生涯（2006）
How knowing Lisp destroyed my programming career (2006)
2009 — 2018，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 2006 年 comp.lang.lisp 邮件列表中的一篇自述，作者回顾自己因掌握 Lisp 而“毁掉”编程生涯的经历：Lisp 的强大让他自满，也让他逐渐脱离主流工具与库生态，最终在职场中落后。文章并非单纯抱怨语言，而是反思程序员如何被自己偏爱的工具塑造，又如何在现实工程环境中失去优势。
为什么经久不衰：它触及语言优越感、工具生态与职业适应力的经典张力，加上 Lisp 社区内部的自省，使这篇近二十年前的反思在今天仍值得一读。
HN 评论精选
作者用 Pascal 写 Lisp 解释器完成课程项目，并认为 Lisp 技巧可迁移到主流语言，不必因不能直接用 Lisp 而沮丧。
我差不多同时学了 C 和 LISP（那时想跑 Unix 还得有台 PDP-11）。大学第一门“杀手课”用 Pascal 教，课程要求做一个持续一学期、分多阶段的符号计算器项目。用 LISP 写大概几百行，于是我用 Pascal 写了一个带垃圾回收的 LISP 解释器，再用 LISP 写项目主体，嵌在 Pascal 源码里。全年级约 300 人里只有我完成了项目，但教授们并不觉得好笑。我从没在生产环境用过函数式语言，但从 Lisp 偷来的技巧用在不少产品里；我也见过别的工程师因不能直接用 Lisp 而沮丧，比如 Apple Newton 从 Dylan 转向 C++ 时，一群失落的 ex-Scheme 黑客抱着 C++ 手册在走廊里游荡。
kabdib查看英文原文
I learned C and LISP pretty much at the same time (back when rocks were young and you needed a PDP-11 if you wanted to run Unix). Then I went to college and the first course in the Computer Science major was a "killer" they taught in Pascal. Okay, so Pascal is a kind of screwed-up C, and I could deal with that. That "killer" course had a semester-long, multi-phase project that was a kind of symbolic calculator (with sets and operations on them). It was maybe a couple hundred lines of LISP . . . so I wrote a LISP interpreter in Pascal (with a garbage collector, natch), then wrote the meat of the project in LISP, embedded in the Pascal source. Was the only person in a class of 300 or so who completed the project that semester, but the professors were not amused with the approach I took. Can't imagine why :-) I've never used a functional language in production, but I've stolen LISP techniques and used them in quite a few products. I never felt frustrated by the fact that I couldn't use LISP or Scheme or whatever in <product> and had to use C/C++/Pascal/Java/C# instead, but have seen it happen in other engineers (notably when the Apple Newton switched from Dylan -- an object-oriented variant of Scheme -- to C++; there were a bunch of forlorn looking ex-Scheme hackers wandering the hallways, clutching copies of the C++ Annotated Reference Manual and trying not to cry).
原文作者承认问题在自身自满，而非语言；Lisp 不能拯救傲慢。
结论无可逃避：问题不在 Perl、C++ 或 Java，而在我自己。我不再是一个很好的程序员了。Lisp 的力量让我自满，世界已经超过了我。如果你自大到无可救药，Lisp 也帮不了你。免责声明：我是 Lisper。
phoe-krk查看英文原文
The conclusion was inescapable: the problem wasn't Perl or C++ or Java, it was me. I just wasn't a very good programmer any more. Lisp's power had made me complacent, and the world had passed me by. Lisp can't help you if you're too smug for your own good. Disclaimer: I'm a Lisper.
批评作者困在舒适区，主张多语言并考虑维护、人员等现实因素。
问题不在 Lisp……问题是他不想离开舒适区。你可以热爱 Lisp、Smalltalk 和所有那些优美语言，但绝不该只固守一门语言。去学另一门，看它的长处；如果它在某些方面稍弱，试着用你学到的漂亮技巧去改进它。解决任何问题可以用不同语言，但某些场景它们不是合适工具，另一些场景你还得考虑外部因素，比如有多少人维护软件、他们是否熟悉这些语言、轮换项目人员是否更容易。每个人都能学会使用某种工具，但使用其他工具的经验可能帮你发现使用新工具的更好方式。
Francute查看英文原文
The problem wasn't lisp... The problem was he didn't want to leave his comfort zone. You can love lisp, Smalltalk, and all those beauty languages, but you should never stick to a single language. NEVER. Go to another, look it's strenghts, and if it's a bit weak on some sides, try to use the nice techniques you learned back to make it better. To solve any problem, you can use different languages. Of course would be nice to use the nicest languages, but in some contexts they're not the right tool, and in others, you should have to consider outside factors like, how many people will maintain that software. All of them knows how to use the powers of those nice languages? Also, do you think would be easier to rotate people on that project using those languages instead of another ones? Everyone can learn to use some tool, but experience using others may help you to discover better ways to use new tools.
真正原因是库生态与协作积累，而非语言本身；从零开始导致落后。
从这个轶事里唯一能学到的是：如今库才是把事情做完的关键。写编译器时，大部分工作得自己做，不太需要外部库；写 Web 应用时，如果你在重新发明 HTTP 服务器、请求分发器、组件加载器、事件处理系统、持久层等等，就没多少时间做本职了。作者的 C++、Java、Python 同事比他完成得多，是因为他们都在彼此的工作上构建，而作者每次都从零开始。0 + 1 个人的工作几乎总是少于（公司所有人的工作）+ 1 个人的工作。如果 Google 用 Lisp，他大概不会“落后”。
jrockway查看英文原文
The only thing to take away from this anecdote is that libraries are the key to getting things done these days. When you are writing a compiler, you are doing most of the work on your own. You don't need much help from external libraries. (Perhaps you need a compiler compiler, but that's about it.) When you are writing a web app (or something similarly "useful"), you aren't going to have much time to do your thing if you are reinventing an HTTP server, a request dispatcher, a component loader, an event handling system, a persistence layer, and so on. The reason the author's C++, Java, and Python colleagues were getting more done than him is that they were all building things on top of each other's work. The author was starting with nothing every time. 0 + 1 person's work is almost always going to be less than (everyone in the company's work) + 1 person's work. If Google used Lisp, he would probably not be "behind".
历次讨论
同类还值得读
用十年时间自学编程（1998）
Teach Yourself Programming in Ten Years (1998)
Peter Norvig 1998 年的经典文章，回应“21天/24小时学会编程”一类速成书，主张真正精通编程需要约十年持续、有意识的练习。
职业与工作方法上首页 11 次 · 2007–2025norvig.com编辑精选如何成为一名程序员：简短、全面而个人的总结
How to be a Programmer: A Short, Comprehensive, and Personal Summary
一篇广为流传的程序员成长指南，作者以个人经验系统总结了成为优秀程序员所需的各项技能——从调试、测试、沟通到团队协作与身心健康。
职业与工作方法上首页 6 次 · 2008–2015samizdat.mines.edu编辑精选不要自称程序员
Don't Call Yourself a Programmer
经典职业建议文章劝软件工程师不要把自己局限在“程序员”这个标签上，而要从公司业务角度说明自己创造的价值；文中讨论了成本中心与利润中心、头衔、求职与职业选择，也顺带批评了学术界的价…
职业与工作方法上首页 5 次 · 2011–2021kalzumeus.com编辑精选创作者的日程与经理的日程
Maker's Schedule, Manager's Schedule (2009)
Paul Graham 在这篇文章里把时间表分成两类：管理者的日程以小时为单位，会议可以填满一天；创作者（程序员、写作者等）的日程则以半天为单位，需要长时间不被打断的连续块。
职业与工作方法上首页 5 次 · 2009–2021paulgraham.com编辑精选为什么程序员的薪酬不与生产力成正比
Why programmers are not paid in proportion to their productivity
讨论为什么程序员的薪酬往往不随其生产力成比例增长：生产力难以客观量化，薪酬更多受组织预算、岗位定价和个人议价能力影响。
职业与工作方法上首页 5 次 · 2009–2022johndcook.com