我对第一份工作记忆犹新。
当然，这得益于我至今仍将许多同事视为朋友，甚至知道其中几位仍在阅读这个博客。(大家好！)
我也觉得那或许是终结的开端。至少就编程而言。
2025年的编程世界
时值2025年。如今我们编写的JavaScript已支持类型系统。它不仅能在浏览器中运行，更可部署于Linux系统。它拥有依赖管理器，并秉承纯正JavaScript风格——设有中央代码库供所有人自由提交代码。如今它主要被用于向毫无防备的服务器植入比特币挖矿程序或勒索软件，但若你需要填充字符串的实用工具，或许也能在此觅得。
当然，我们不再亲自 编写 JavaScript代码。我们让自动修正机器编写代码，并不断抱怨直到它生成足够可信的内容。通常它能做到，且仅有20%的概率安装恶意包——最多30%。
所幸当需要手动修改时，编辑器会为我们保驾护航。最受欢迎的“VS Code”仅需几GB内存即可渲染文本。它自带网页浏览器——毕竟现在什么软件都得带浏览器。还能执行花哨的重构操作，比如重命名变量(仅限单个文件内)。
为测试应用程序，我们定期进行构建。在配备约16个核心、每个核心运行频率3GHz的现代计算机上，TypeScript编译并运行仅需数秒。
工作完成后，我们会创建“拉取请求”。这是在单一公司内部模拟开源开发的方式——众所周知，这才是唯一可行的工作模式。通常流程是：代码被下载到另一台计算机上构建，数小时后同事前来要求修改几个词。修改完成后，计算机需重新构建全部内容，次日该同事才会批准代码合并到主干。
合并完成后，我们将该 JavaScript 代码打包成“容器”——这个花哨名词其实就是“大杂烩”的意思。打包过程耗时20分钟，因为每次操作时系统都会下载整个 Debian 软件包仓库，具体原因无人知晓。
当然，所有JavaScript依赖项也会被重新下载一遍。
接着我们将容器推送至“注册库”。有时能成功，有时安全扫描器会报错——因为容器里存在不安全的Perl版本。我们本不需要Perl，但它就在那里，没人知道如何清除。于是我们干脆关闭了扫描器。
接着，我们编写大量YAML配置文件，告知名为“k8s”的系统如何运行容器。(“K8s”曾有特定含义，但自2019年的命名之争后，我们已无足够字母完整拼写其全称，其本义亦随时间流逝而湮灭。) 与JavaScript不同，YAML不进行类型检查——事实上也 无法 检查，因为我们用字符串模板语言将YAML片段嵌套在其他YAML中。我们一致认为这才是最棒的编程方式。
我们的k8s集群运行在“云端”。它由一堆在Linux上运行的服务构成，但我们并不直接运行Linux——而是租用按小时计费的虚拟机，每月成本约等于直接购买一台计算机。这么做是因为如今没人知道如何给计算机插电源了。
我们将YAML发送至集群，它会吞噬、消化这些数据，然后执行随机操作。理想情况下会运行某个程序，但也可能拒绝执行、启动其他程序，甚至关闭某些组件。由于无法通过测试验证，结果完全不可预测。
因此我们另建独立集群，专门验证向YAML神明献祭的纯洁性。
这里似乎涉及过编程，但我已记不清具体细节。
十五年前
原来我已年迈。但岁月未湮没我对变迁的记忆。
2010年我开启了第一份 真正 的全职工作。
我们使用Java编程——这种通用型语言冗长繁琐，通过强制重复输入参数并反复验证来实现类型安全(除了null，我们竭力避免使用它)。
如同JavaScript，它的编译速度极快，同样只需几秒钟。当然，这还是在我的单核2GHz电脑上测得的。
编辑器也很酷。我们使用Eclipse，它有点像VS Code。它还能执行重构技术，不过更智能些：能提取并内联函数、类、接口等。它还能在输入时实时编译代码，因此每敲击一次键盘，就能编译应用程序并运行测试。
我们当然编写了测试。通常先写测试，然后持续运行。我们采用了一种名为“相互交流”的奇特方法：先讨论待实现的功能，再将其转化为可验证的代码。这些测试会持续运行；通常运行全部10,000个单元测试只需一分钟左右，但若赶时间也可选择性运行部分测试。
有趣的是，当时的运行速度竟与如今相差无几。这着实令人费解。
当然，我们直接将代码推送到主干分支——毕竟当时采用结对编程模式。随后我们便着手处理新任务，通常在咖啡休息后开始。此时我们会通知测试人员检出变更内容进行审查。
当时没有容器技术，我们制作名为“JAR”的文件——这是包含应用程序及其所有依赖项的压缩包，从Maven Central获取。(Maven Central类似于Java领域的NPM，且会审核提交者及其域名资质才允许发布。) 这种方式虽与容器化不同，却同样会陷入依赖地狱——这种痛苦我绝不愿他人经历，但至少当时还能勉强运转。
我们会在计算机上的Linux虚拟机中，通过Apache Tomcat等Java服务器运行该程序。部署通过“Puppet”工具完成；如今或许会用Ansible，但无所谓了。
这台计算机位于数据中心内。
数据中心就在街对面。若计算机故障，我们随时能跑过去重启。
有趣的是：它从未出过问题——因为搭建者技艺精湛，因为系统负载从不超负荷，更因为我们时刻守护着它。
我怀念那些日子
回想往昔，我仍记得编写Java代码、与老同事结对编程的时光。
我们技艺精湛，更得益于得力工具的支撑。Eclipse可靠无比，它实现的诸多惊艳功能至今无人能及。Maven以深思熟虑的方式管理依赖关系，优雅解决了命名空间和信任机制等难题，其创新至今无人能复制。我无比怀念部署到真实物理机上的日子——那台属于我、能亲手触摸的机器。
每当意识到构建部署竟在十五年间变得 更慢 而非更快，我仍深感震惊。当年从代码到上线只需不到一分钟，如今却要耗费数小时甚至 数天 才能完成合并部署。即便将应用推送到k8s也是场折磨，尤其当所有操作都必须先经过预发布环境时。
我不太理解为何我们停止招聘测试人员，但真希望重拾这个传统。我喜欢身边有擅长“破坏”的人存在——当他们站在我这边时，我反而感到安心。
当然也有进步之处。比起Subversion，我更倾向使用Git。容器技术若设计得当(即不用Dockerfile构建)且部署合理，我其实相当欣赏。云计算在特定阶段也颇具价值，尤其对初创项目而言。
但这个世界……实在令人厌恶。
问题根源何在？
我一直在追溯问题源头，如今终于找到关键催化剂。
NPM的出现。
这并非NPM的过错，而是它创造了可能。
要知道，NPM让Node.js(进而让JavaScript)成为真正的编程语言，这既是福也是祸。
我们还见证了React的崛起——这或许是前端编程史上最惨痛的悲剧(作为曾经的React拥趸，我如此评价)。
随后，由于能在浏览器中创建应用程序，Electron应运而生。如今万物皆可浏览器！
我热爱编写JavaScript，也欣喜于能在服务器端运行它。但这并不意味着我认为它适用于所有场景。
我真心渴望重置现状，回归为具体任务选用合理工具的本质。
哪怕只是小小一步。
本文文字及图片出自 Programming peaked
这篇文章以各种形式不断流传，实在令人厌倦。是啊，让我们铭记25年前所有美好的事物，而遗忘所有糟糕的。将之与当今所有糟糕之处并列，却刻意忽略所有美好的。拜托，伙计。
若觉得当下糟糕，何不亲手改善？世界是你的游乐场。没人逼你用YAML、Docker或VS Code——无论你抱怨什么。Eclipse依然存在！街角还有数据中心！走过去把服务器挂上机架，放上你那套几乎不做类型检查的Java 1.4代码，开干吧！
> 世界是你的游乐场。没人逼你用YAML、Docker、VS Code或任何你讨厌的东西
除了你的未来就业前景。
技术选型总有合理与不合理的理由；“能否招到人做这个？”是个很合理的理由，但这直接导致了简历驱动开发——我们都在追逐招聘广告撰写者认定为“好”的技术栈。
那些在“MAC & PC”里把“MAC”大写的家伙，那些把Java和JavaScript混为一谈的家伙，那些要求你掌握三年前才问世的技术却要十年经验的家伙。
没错，问题就在这里，所有这些变革背后的核心是协调性。我们采用容器化技术来协调使用多种运行时环境的能力；我们用TypeScript和Python改造Web技术栈，让前端和数据团队也能在后端如鱼得水；我们创建日益复杂的软件包仓库，只为简化层层叠叠的软件项目。
我认为撰写此类文章的人们真正向往的是更小 规模 的事物。工业化钢铁生产客观上优于传统铁匠铺，但亲手锻造刀具套装确实更具个人温度。炼钢工艺在引入复杂机制、危险污染和物流体系前并非更优，但当它还是手工艺时，工作过程带来的满足感更为强烈。
说得太好了——这正是我的真实感受。
当然，业余项目可以随心所欲。但在职场中，这些决策往往由他人代为作出。而这些决策随时间推移，却因错误原因不断改变。
顺带一提：既然提到了k8s，也该提j8t。
> 但“在工作中”这些决策通常由他人代为决定。
所谓“如今多数雇主决策糟糕，当年却决策卓越”的说法显然站不住脚。作者生动回忆了在某家靠谱Java公司的经历。即便如此，我仍强烈怀疑他们描述的“一切完美”是否属实，但确实听起来相当不错。但当时许多企业毫无理由地固守C++，纯粹因惯性使然，通常还使用仅限Windows环境的Visual C++ 6专属方言。他们的“构建服务器”彻夜运行，下午晚些时候提交代码，次日清晨才能收到编译错误反馈。所谓的“源代码控制”依赖全公司范围的文件锁定机制，若忘记下班前提交文件，就会接到电话被召回办公室。与此同时，半数网站都用Perl编写成史诗级的意大利面式代码。PHP部署起来令人愉悦(至今仍是如此)，但调试起来却痛苦不堪。
若你对这些技术细节深有共鸣，请寻找同样重视它们的雇主。这样的公司过去存在，现在依然存在。
> 他们的“构建服务器”整夜运行，下午晚些时候提交代码，次日清晨才能收到编译错误报告。
说得好。当人们抱怨Rust编译周期长时，我们需要保持客观。即便如此，它也比填写纸质的FORTRAN或COBOL编码表格好得多——那些表格要送去计算机房打孔制成卡片，下周才能拿到行式打印的程序输出(或编译器错误)。
Rust臭名昭著的编译时间之所以格外刺眼，一方面是因为其他系统语言能轻松跑完几圈，你的Rust构建才刚完成；另一方面则是因为连老奶奶都坚称Rust快如闪电。
直到你不得不从零开始编译程序，或是启动CI管道构建时才明白真相。
这就像经济增长：先是低迷，接着上升，如今却在自由落体
你描述的正是这种状态：编程领域曾一片混乱，突然迎来上升期，直到现在开始崩盘。
这并非对问题的反驳。而是刻意挑选两个同样糟糕的时刻，如同所有技术讨论那样，刻意忽略那个拥有海量资金、强大支持的庞大互联网生态——它比以往更糟糕。
这如同抱怨西部手枪与核武器同样致命，却忽视其规模与杀伤力的天壤之别
并非所有人都享有生活在就业机会丰富地区的特权。
深表赞同。
我们深信在这个领域自己毫无自主权，总被高层那些刻薄的坏蛋们推来推去。
Visual Studio 6时代的人们真的一晚只编译一次吗？那时候可是有奔腾2和奔腾3处理器的。
在质量平庸的大型C++代码库中(我指的是某大型复杂机械制造商的案例)，确实如此。
开发者当然会本地编译自己的单元(所谓“单元”是指按某种希望是逻辑的方式聚合的文件集)。但除非夜间构建完成，否则无法100%确定单元在整合到主代码库后能否正确编译。比如修改过.h文件时，基本可以确定没问题；但若涉及.h文件，就必须格外谨慎，最坏情况下得经历为期一周左右的“编辑-编译-测试”循环，每个步骤耗时一天。我不完全清楚他们如何防止编译失败影响其他团队，但并非总是成功(我认为他们采用分层构建服务器架构，类似GitHub Actions模拟“当前PR合并到主分支”的夜间构建机制)。
Visual Studio 6本身其实相当不错。虽然界面功能有限(但因此运行足够快)，编译小型项目完全没问题。事实上它以编译速度快著称，我并非暗示VC++6必然导致通宵构建——只是两者时间上巧合。实际上结构良好的中等规模C++项目(有人用Pimpl模式吗？)在当时的计算机上重编译速度可能相当快。
大型代码库的构建确实需要数小时——微软Excel团队曾对破坏构建的人发放惩罚性“棒棒糖”，导致百余名成员无法查看测试新版本。
1990年代Linux内核编译耗时以小时计，而其代码库规模相较许多项目已属精简。没错，编译确实缓慢，慢到连xkcd漫画都专门为此创作过。
不过核心问题并非整体编译速度，而是变更后的迭代周期。我实在难以相信当时开发者每天只进行一次编译，每次迭代都要重建整个庞大程序。这正是编译单元存在的意义。
昔日的“糟糕决策”与当今的“糟糕决策”根本不可同日而语。这根本不是同一类问题，甚至不是同一类运动。
jubernetes？
这就是“让我们用正统企业级Java重写k8s，就像它最初就该这样实现，别搞什么Go语言的胡闹”项目。
有趣的是，我记得Kubernetes在v1.0之前确实是用Java写的！
jubernetet
> 而这些决策随时间推移因错误原因而改变。
你可曾想过，或许你根本不理解当初决策的缘由，所以才认定它们是错误的？
我只是不同意这些理由，而你似乎暗示所有决策都是正确的。
理由永远如出一辙：20%源于某些变革确实是改进，80%则是迷信崇拜——只要搭好容器框架，念对YAML咒语，你也能成为谷歌… 接着进入集体惯性阶段——组织已然丧失创新能力，只能机械重复这些做法，直到下一个流行趋势出现。新趋势虽能修复旧趋势的缺陷，却又引入另一套早已解决的问题，因为这个行业在历史认知上极其短视。
谷歌这么做，或许也能让我的小公司成功吧？
> j8t
Javascript？
这样就能解决商标问题了…
> 既然说k8s，也该说j8t
多出的那个发音音节大概就让它成了k8s吧。¯_(ツ)_/¯
但这只在书面形式中使用。你不会真的念成“kay eight es”吧？
对西班牙语使用者来说，Kocho需要卷舌发音。
听起来像“coso”(意为“小玩意儿”，略带贬义)。
哈哈，天哪，才不会。那太傻了。
显然是“Kates”。就像“sk8er boy”那样。
i18n怎么念？
我脑子里？
像是把“internationalization”含糊带过再拼上18。“伊利-艾汀-永”
(总之我讨厌这类数字缩写，对圈外人简直晦涩难懂)
我最爱的T恤是件定制黑衫，用白色打字机风格编程字体印着`f2k i18n`。(感谢Roman！)
多数人对此感到困惑。当我开始解释时，听起来像个讨厌外国人的混蛋。
街上的程序员们会指着它微笑。若他们从事`l14n`工作，就会走过来给我一个拥抱。
难道不是l10n吗？
制度化
眼十八因
凯特派 vs 杰特派？
凯特的
认真的吗？要是团队里有凯特怎么办？
结果她得替那些不懂上下文的人承担所有麻烦的责任
有时是凯特，有时是杰森，有时是亚马尔。
但永远是丹尼斯。
申请时自动系统显然会直接拒绝他们的简历
> 是啊，让我们铭记25年前所有美好的事物，遗忘所有糟糕的。再把这些与当下所有糟糕之处并列，却刻意忽略所有美好。拜托兄弟。
这话有道理。如今看到糟糕代码时，我试图剖析其缺陷，才发现人们25年前完全在重蹈覆辙。
如今代码量激增，我们站在更高耸的“架构”基座上，试图满足更庞大的期望堆栈。关键在于：糟糕代码的负面效应似乎比优秀代码的正面效应更易累积。而满足代码增量需求，必然需要扩大编码者的基数。
> 若觉得现状糟糕，何不亲手改善？世界本就是你的游乐场。
我赞同此观点。许多现代期望是人为制造的，过度强调形式而忽视功能。即便并非如此，许多现代技术也只是徒有其表的模仿。只要相信你的机器(https://thundergolfer.com/computers-are-fast)，本地就能实现很多功能； https://www.youtube.com/watch?v=ucWdfZoxsYo)。
针对PAPER项目，我锁定Python 3.6+版本(新增
pathlib.Path与f-字符串，并升级SSL版本)，计划永久支持该版本(需分叉部分依赖库)。他们不要解药，只想找点抱怨的对象。
我认为退后一步审视当下实践方式，是极好的自我认知锻炼。
我2003年开始第一份编程工作。有些方面进步了，有些则退步了。但唯有通过自我反思，我们才能提升软件开发的“工艺”。这正是80年代“软件危机”期间发生的事，也是“瀑布式”开发被“迭代式”开发取代的缘由。
如今人工智能辅助编程带来如此颠覆性的变革，正是检验开发流程能否进化的绝佳契机。
说你自己吧。这里暴露的病态/神经症…“治疗”…“贱人”…说真的，我们还在讨论软件吗？
是这样吗，医生？
是的，问得好。不过别费你那小脑袋操心啦！你不是第一个被自己的药治得皮薄的病人，也不会是最后一个。
> 若觉得现状糟糕，就亲手改善它
这完全忽略了我们是为老板而非为自己做事的事实
没错，我的第一反应是： “行吧。那就别干蠢事了。”想用1999年的编程方式？请便。比如我基本不用AI，毕竟还没发现它能带来净收益。
昨天刚和朋友讨论过用老技术克隆热门网站的事。用mod_perl和db2打造出有竞争力的替代品完全没问题。
从技术角度看，如今开发栈的选择已不再那么关键。
VS Code倒不必强求，但若公司统一工具规范，YAML和Docker可能难免。C#团队或许仍强制使用Visual Studio。虽说“工欲善其事必先利其器”，但对于标准CRUD网页开发，现有工具已足够丰富，实现快速交付的途径更是多种多样。
至今想起我的笔记本运行CRUD应用的速度竟是云服务器的三倍，而我们为此支付的费用却高出数倍，仍不禁莞尔——当然我也深知，再也不想通过远程桌面登录生产环境，翻阅IIS或Windows日志了。
我确实观察到，招聘市场的激励机制正导致人们在选择更复杂技术时做出妥协。
人们高呼要保持技能更新，于是人们选择热门技术——即使产品根本不需要，因为这能带来个人利益。这反过来促使企业只招聘掌握该技术栈的人才，而企业越是这样做，就越多人会基于技术选择来争取自己能胜任的最佳职位。
我们 绝对、百分之百地 看到这种情况正在大型语言模型AI领域上演——若你需要更确凿的证据。当前发生的一切，不过是自互联网泡沫破裂前夕以来所有不良实践的更甚之例。
正因如此，除非存在重大特殊原因(法律合规、安全需求等)，否则我绝不会建议部署本地化应用或构建纯本地程序——尤其当公司其他产品线都已选择云端时。
原因何在？因为要说服下一任雇主相信这是正确选择，实在太过艰难。
编辑补充：正如其他人的观点，我曾主动选择陷入微软/Azure/Windows的地狱圈，但要挣脱重返其他生态，无异于同时承担两份全职工作，还要在脑中并行处理两个技术体系。
我既认同又反对你的观点。
一方面：没错，这位开发者显然选择了职业/语言专精方向，让自己深陷堪称最糟糕的工具链泥潭。我无法想象如此糟糕的工作流程，若这是我的日常，我的抑郁程度会远超现在。
而且 ，我们行业中如此之多——或许不是全部，但相当一部分——的工作流程与这般境况并无二致，在我看来正是对我们这个行业的控诉。借用《莱特肯尼》里那位冰球教练的不朽名言：这他妈的简直丢人现眼。
如今那么多主流软件都只能在网页浏览器里运行，因为给Windows、Mac和Linux编程实在“太难了伙计们”——对微软这种小豆丁(市值3.62万亿美元)来说，在人工智能垃圾上烧几百亿都嫌多，这简直他妈的丢人。
我手机里半数应用都是这么写的，难怪它们动画帧率勉强30Hz，S3云服务一掉线就彻底瘫痪，好不容易运行时还让手机发烫。就为了让我在办公桌前控制恒温器？他妈的丢人现眼。
我的台式机之所以还能撑住，纯粹因为它比90年代那台老古董强上几个数量级，可实际提升却微乎其微。早在2000年代初，我就能一边玩《帝国时代》，一边用TeamSpeak和朋友聊天。如今我的电脑照样能做到这些，甚至还能通过Discord直播游戏画面让朋友们互相观战——这本该很酷，可光是开着Discord就让我掉10帧。出门旅行时？天啊别提了，酒店WiFi下Discord简直卡死，明明是标准DSL网速啊。虽然不算“火速”，但TeamSpeak早在2000年代就能在真实DSL连接下，忍受着DSL延迟处理语音通话。这简直他妈的丢人。
如今所有软件默认自动更新，当这种机制成为好事时反而值得注意。通常这意味着已知功能布局会因看似随意的原因改变，有时还会注入更多黑暗模式。Discord虽非针对，但他们在这方面绝对是混账透顶。我发誓他们开发人员打个喷嚏都要推个“更新”，每次启动我得安装18个更新——而我可是高频使用！如此频繁迭代，我却说不出他们最近到底新增了什么功能。真他妈丢人。
人们总说“他们本可以做得更好”‘我们知道能做得更好’“这些公司或应用并非顶尖”——好吧，但它们可是行业巨头。试想美国普通汽车的油耗糟糕透顶，需要频繁维修，设计严重背离用途，价格还贵得离谱…
哦，这种事也真发生了。看来我这个比喻又让另一个行业难堪了。
更好的工具早已存在。问题不在于能否做得更好，而在于当今多数程序员选择平庸。
有时你能避开这种平庸，但更多时候你被迫在这片沼泽里挣扎。
> 选择
有时程序员根本没有选择权。商业驱动下的平庸化趋势确实令人抓狂。
确实有时如此，但我在实务中观察到更多是程序员自食其果。这叫冒牌者综合征——他们心虚却不敢示弱，四处搜寻选择的线索。猴子看见就学，然后像猴子般猛敲键盘直到看似能用。
老家伙总说社会要崩溃了；当年在他那个年代……
真希望人们别总用“人身攻击式嘲讽”来回复。我喜欢妙语，但这类回复既缺乏实质内容又显得敷衍，完全没针对核心问题。
我确实认同，将过去与现在相比较往往充满复杂的微妙之处，人们也确实倾向于用玫瑰色眼镜看待过去。但在我看来，塔尔瓦的博客文章更多是关于他们当下经历的个人反思，而非某种关于问题根源的科学论述。
批评有理；我并非人身攻击，而是总结(正如我回复的评论所指出的)这类反复出现的文章类型(不仅限于编程领域)。这种思维模式令人疲惫，将其核心论点拆解为“我年轻时更喜欢过去”确实有其价值。
若标题是“Java/JavaScript的巅峰时刻”或“我对XYZ的反思”，且行文如此，我根本不会多想。但宣称编程在15年前就达到顶峰，让我觉得自己的总结无可厚非。
终有一日你也会变老，届时看着年轻人跌跌撞撞地犯下完全可避免的错误，看着他们遗忘那些你毕生所学却未被好好传授或被刻意忽视的教训，你会发现世界截然不同。
历史上各时期都有老者高呼社会因新生代软弱而崩溃的记载。关键在于，或许他们始终正确，而新生代终须成长承担责任？又或许有时他们过于正确，导致社会在局部区域真正崩溃。
“艰难岁月造就强者。强者创造繁荣。繁荣滋生软弱。而软弱者终将重启艰难岁月。”
——G·迈克尔·霍普夫《幸存者》
深表赞同！说实话，我早已厌倦那种“老人们总爱这么说”的刻板论调。某些事物确实会明显恶化，代际间的抱怨往往源于真实存在的困境。
我总爱举这个例子——身为棒球迷，我发现每代球迷都抱怨三振出局者比从前多了。这是棒球迷变老的必然现象吗？不！这是真实存在的趋势。近一个世纪以来，三振出局率确实逐十年攀升。
所以有时问题确实存在。环境生态崩溃？真实存在。每代人注意力持续时间缩短？真实存在！政治日益恶化？或许1860年代更糟，但过去50年的下滑趋势相当明显。日益自动化的编程范式效率低下？真实存在！
有些事情即使是老一辈在说，也可能是事实。
他们确实错了，我保证自己年老时绝不会抱持这种态度。这正是我最厌恶的人群类型；而我的核心观点正是：自古以来老人们总在哀叹社会崩溃，可现实是——我们正处于前所未有的繁荣时期。
说句公道话，我赞同你的观点。保持对新事物的热情完全可行。关键在于…亲自尝试！即使他们重蹈二十年前类似尝试的覆辙，也要发掘其中的 亮点 。
比如React刚出现时，我完全有种Delphi的既视感。后来他们重新发明了MVC(不是Rails那种，是纯正的MVC)，还给它冠上“单向数据流”的华丽名号，自诩聪明绝顶地做着炫技的大会演讲，我当时就觉得“这不过是换了个更糟的名字的MVC罢了”。
但React确实做到了让每个组件都具备可复用性。就像在Delphi里，你有个“Form”可以拖放“Controls”，高级用户还能自定义控件。但多数人觉得自己不够高级，导致代码复用一团糟。React让每个控件(咳咳组件)都可复用，因为使用组件就等于创建组件。这主意不错！纯函数式UI设计同样是好主意！不过他们抛弃面向对象而非改进它，这绝对是个糟糕决定——但归根结底整体依然出色！况且Delphi不必处理HTML和CSS的混乱局面，开发体验本就轻松得多。
但确实，我们这代人普遍看到了相同问题：这不过是Delphi的翻版，只是犯了不同的错误，于是大家只盯着这些错误不放。这纯粹是态度问题。
如今我沉浸在信号、SolidJS和可观察对象的乐趣中，不禁困惑：如此优雅又高效的技术为何迟至今日才被发掘(或者说，才变得足够人性化并主流化)？
> 我保证等我老了，绝不会抱持这种态度。
在我听来这简直是天真得可笑。这就像七岁小孩说“大人们整天坐在办公桌前做无聊的工作，我讨厌这样。等我长大后，我发誓要当宇航员或打职业棒球。”
并非他们不真诚，而是人们不该对尚未理解的处境妄下承诺。虽然其中少数孩子或许真成了宇航员或棒球运动员，但99%以上许下承诺的人并未如愿。成年后的阅历让他们明白：即便不喜欢文职工作，也有其存在的价值；而对许多人而言，他们其实享受着这份工作(比如热爱编程的人)。
所以即便百万年轻人曾怀抱同样的梦想，当他们真正踏入职场时，观点却神奇地转变了——这并不意味着你就是那个打破传统的人。
你或许真能成为宇航员，但听众们基于过往可靠证据，完全有理由认为你不会。
> 他们尚未理解的处境
你这里就错了——我理解。你纯属胡言乱语；在我听来你显得天真
读读你刚写的内容。你只是在宣扬信念，而非提出实质论点。
你期待学习吗？变得更睿智吗？
若真如此，终将获得年轻人尚未具备——或永远无法企及的智慧。年轻人虽在诸多领域开辟更优路径，却在其他方面出现退化。他们缺乏你(及你这一代人共有的)经验积淀。
正因如此，唯一看不见真实退化迹象的老人是……坦白说，除却那些不幸罹患痴呆症的老人，我尚未遇见过此类长者。
此外，每种新颖(或看似更优)的操作方式，都需重新发明诸多显而易见的事物。许多人甚至意识不到这些问题早已被前人解决。这需要时间。
因此，退步在所难免。
况且即便解决了退步问题，也无法保证新方法真正更优。毕竟复杂变革的全部影响难以预见。
若有人尚未意识到——当今大量粘合代码的存在、为微小差异重写通用算法的现象、各类工具平台与依赖项的混乱拼凑，以及它们各自的怪癖——这些本就是次优解……
但当下的痛点终将催生新方法。周而复始。
进步从来不是平滑或单调的。
说你不会注意到这些问题，是种赞美而非批评。
我的意思是，一个对我一无所知的人竟称我天真，还对我的未来妄下断言——我确信这些预言会落空。时间自会证明，但对方评论毫无实质内容可讨论，故我才回应。
你刚才说的许多观点我并不反对，但不确定你究竟想讨论什么
我确实后悔花时间读这篇文章并参与评论区讨论——这确实太天真了！
可以理解。
用“天真”形容你确实措辞强烈，但语境中更多是反讽与幽默，而非不敬。
任何有所领悟的人都会怀念曾经的天真模样。我也曾与你有过相似的想法。
(我不认为世界正在崩塌，但确实看到编程领域出现大量不必要的倒退：疯狂、癫狂，无处不在！:)
> 任何有所学问的人都会回望自己天真无邪的模样。我也曾有过与你相似的想法。
庆幸自己早年上网时(2000年代初)大多使用匿名身份。那时我常对刚接触的事物抱持极端观点，却缺乏经验去领会其中的微妙差异。如今我的政治立场已彻底翻转，回望当年激进的青年岁月，遗憾地发现许多年轻人仍在重复我当年因无知而深信的空洞谬论——那些根源于我成长过程中灌输的简单粗暴观念。
> 我常对刚接触的事物抱持极端立场，却缺乏经验去领会其中的微妙差异
我不会这样做；这正是我与本帖诸位存在差异之处，也是我不担忧此处警示的原因
然而你曾写道：
“…这正是我最厌恶的人群类型；我的核心观点在于：自古以来老人们总在宣称社会即将崩溃，可现实是——我们正处于前所未有的繁荣时期”
这观点相当激进。况且历史上几乎所有文明都曾崩溃过。崩溃时生活往往陷入绝境，无数人丧生。我说的不仅是古罗马、古希腊、复活节岛，或是数十个帝国的覆灭，更包括近年的南苏丹和海地。
帖中有人称你天真。我虽不愿如此贬低你，但从这些言论来看，其中充斥着熟悉的过度自信——这让我想起自己二十多岁时说过的话。
这可真是证明他观点的好例子
> 他们当时是错的
如果你认为他们至少 有时 是正确的，那么你将历史记载中各种社会经济崩溃的案例归因于什么？
如果我每年都预测经济衰退，终有一天会猜中
不过我不确定这是否完全等同。我们讨论的是人们观察特定文化趋势，并针对具体因果关系提出有理有据的论述，而非简单宣称“X事件必将发生”。关于人类社会运作机制的具体模型与假设，往往能通过历史实例得到验证——它们不仅预测终局状态，更揭示跨越长期时段的事件序列。
当人们声称看到历史重演时，值得倾听他们的见解。
我的意思是：若每代都有老人高喊“社会正在崩溃”，他们就错了——即便在局部层面看似“正确”
(坏钟一天也对两次)
我乐于倾听有理有据的论述；但将警句当作事实是荒谬的；宣称编程在15年前达到巅峰更是荒谬
> 我的意思是，若每代都有老人高喊“社会正在崩溃”，他们就错了——即便在局部层面看似正确
但每代人高喊“社会正在崩溃”的频率并不相同。总有一群人秉持“别踩我草坪”的心态，但若排除这类人，真正指出世界正走向危险境地的现象在不同时代并不均匀。三十年前几乎无人——即便有人——认真提出过此类论点。
那些真正提出合理论证(而非仅仅抱怨脱离舒适区)的人，绝对值得认真对待。
> 声称编程在15年前达到巅峰是荒谬的
那么你衡量的是什么？在某些维度上它确实15年前就达到顶峰了。你个人是否认为这些维度重要，当然是个主观问题。
Reddit历史学家问答版有个有趣的讨论串：“”"'艰难岁月造就强者。强人创造好时光，好时光造就弱人，弱人引发艰难岁月*“是否准确反映了不同文化中历史文明的演变？”"
结论摘要：该箴言解释历史的唯一方式是强化确认偏误——它看似印证了我们对世界现状及其成因的既有认知。唯有担忧所谓男性气质危机者，才会关注'软弱之人'及其可能引发的麻烦；唯有渴望将自身或特定群体视为'强者'者，才会相信此类人的存在本身就能创造更美好的世界。这与历史毫无关联，纯粹是刻板印象、偏见与歧视的产物。它最初不过是毫无根据的道德寓言，至今仍未改变本质。"
https://old.reddit.com/r/AskHistorians/comments/hd78tv/does_…
该回复完全曲解了引文本意。其核心在于阐述：那些秉持正直品格、愿意且能够付出努力、克服困难去建设更美好未来的人，通常能比无所作为者创造更美好的成果。
这本质上是警示世人的真理——被忽视的问题不会自行解决，与性别或性别刻板印象毫无关联，此乃语言误解。在此语境中，“men”具有中性含义，意指“人们”。在古英语中，“men”明确表示中性，而男性则使用不同词汇“wēr”，该词至今仍在某些场合使用，例如“werewolf”(狼人)即源于此。
颇具讽刺意味的是，Reddit、r/AskHistorians及整个人文领域本身就带着强烈的偏见视角。和其他人没什么两样。
我不明白你的意思。我没看出偏见，观点陈述很明确：所谓“软弱男性”的概念值得怀疑。若你不同意，请提出实质性论据。
若你看不见政治话语中的偏见(而这一切本质上都是政治话语)，那么你极可能正与这种偏见同流合污。
物质丰裕滋生安逸，安逸催生懈怠，而懈怠会破坏社会结构——它鼓励追求即时满足而非长期维系。
人们担忧男性气质的根源在于：唯有通过结构化、利他的社会出口，男性气质才能避免毒化社会。一群迷失方向或误入歧途的男性群体，具有极强的腐蚀性与危险性。他们既能从内部腐蚀社会根基，也能使社会易受外部颠覆。
社会之所以宣扬力量的修辞，是因为若一个社会未能建立培育能力、责任感、目标意识及利他抱负的体系(尤其针对其最冲动成员)，便会变得脆弱不堪。
这只是你的观点，但正如我所言，将此视为主流见解并指责异议者有偏见是站不住脚的。你回避倾听、理解并挑战历史学家的论述，反而选择逃避思考——考虑到你对强人政治的立场，这着实讽刺。
我虽非史学家，但可质疑以下观点：在欧洲封建制度下，当仅贵族享有作战特权而九成民众为农时，针对年轻男性群体宣扬力量与男性理想的修辞是否缺席？抑或两千年前耶稣已挑战传统意义上的男性力量观，主张真正的勇气在于爱与宽恕？时尚服饰亦可佐证，但只需审视西欧国王肖像画，便足以重新审视传统男性气质的样貌。
依我之见，你的论调实属近代产物(故非传统)，恰与民族主义兴起及发动全面战争(另一项现代发明)所需的兵源需求同步出现。
你大可持异议，我乐于倾听反驳，因我并未将你视为偏见者。
> 与其试图理解并质疑历史学家的论述
不过是某位自诩历史学家在Reddit发帖罢了。别把这当作学科的统一权威之声。
> 我本可继续探讨服饰潮流，但或许只需审视一幅西欧国王肖像，便能重新审视传统意义上的男性气概应有的模样。
你将审美层面的男性气概与功能层面的男性气概混为一谈，这是范畴错误。该箴言探讨的并非17世纪男性的着装方式或身份标识——而是何种男性能够 维系文明 。
在此语境中，“强壮男子”指具备纪律性、能力、长期责任感及风险承受意愿的个体，他们能建立、维系并捍卫维系社会稳定的制度——尤其在艰难环境下。这是社会学概念而非美学概念，与你个人对特定男性气质文化表达的喜恶毫无关联。
你同样在预设“好时光=安逸=软弱”的逻辑，而我链接的长文正是为驳斥这种观点。你的论述暗示了相反结论：稀缺与饥荒通过鼓励长远规划而非短期维系，反而能 强化 社会结构。事实上并非如此。匮乏只会催生弱肉强食的短期生存策略——从偷窃邻居粮食、吃掉来年种子，到宰杀农场犬、变卖农机甚至食人，最终导致贫瘠环境、疾病蔓延和火灾隐患，因为人们无暇顾及生存之外的任何事务。
反观丰裕状态：人们得以留种、储备过冬粮食、腾出资源用于洗涤卫生、医疗救治与病后康复，法治得以建立并执行，民众从温饱耕作与觅食中解放出来，从而发展冶金技艺、进行发明创造、练习射箭，并投入建造教堂、参加礼拜等社会建设活动。
> “ 无所事事或方向迷失的男性群体具有极强的腐蚀性与危险性 ”
若他们“极其危险”，岂非正彰显其“强大”？这些本应是“好时光”造就的“软弱男性”，不是吗？他们是弱势时代造就的强者，却又通过腐蚀社会制造弱势时代？还是说他们天生强大，与时代无关？这真符合谚语的本意吗？
> 稀缺与饥荒通过鼓励长远规划而非短期维系，强化了社会结构
饥荒与“艰难时期”并非同构关系，尤其与谚语所指的自酿苦果截然不同——后者指社会自我维持与对外竞争能力遭无谓削弱的境况。
> 若他们“极其危险”，岂非正因其“强大”？
我所言是腐蚀性与/或危险性，而软弱恰恰兼具这两重特质。
你提供的链接并非反驳证据，而是政治立场。存在合理论据支持不同观点。
> “饥荒不等同于艰难时期”
无人声称二者等同
> “尤其不是谚语所指”
这句箴言并未说明其指涉对象，你是在凭空杜撰，使其符合你预设的结论(这便是偏见)。若你以此论证观点尚可理解，但若仅凭“我臆测它另有深意，故你谬误”便断言，便成了问题。所谓“人为制造的艰难岁月”——例如什么？若农耕懒惰不会导致冬饥荒…公元元年社会还有比这更严峻的困境吗？所谓“不必要地削弱”——究竟被谁或何种效应削弱？
> “ 我说的是腐蚀性与/或危险性，而软弱恰恰兼具这两种特性。 ”
别扯了。这种软弱有量化标准吗？它真的存在吗？
> 这句箴言并未说明其指涉对象
如此便无法提出可证伪的论断。若“艰难时期”‘软弱之人’“强悍之人”皆无稳定定义，该循环理论便无法解释任何现象，可随意套用在任何叙事中。其间不存在可辩论的正反立场。
事实并非如此。此处“艰难时期”特指制度衰败、自满心态与短期主义累积引发的内部后果，而非自然灾害。因此你举的饥荒例子毫无关联性。
> 这种软弱能否量化？它是否真实存在？
社会学概念的评估依据是其广泛影响，而非单一量化指标。制度效能衰退、规范侵蚀、问责机制削弱及集体目标丧失——这些现象既可被观察，又具有历史周期性。
你关于安逸与自满的论述，在资源匮乏情境下同样成立甚至更为贴切。匮乏直接催生短期思维——既无未来可规划，亦无根基可维系。当绝望加剧，人们转而投机取巧、相互剥削时，社会纽带便随之瓦解。原文表述过于简洁，这种过度简化未能把握复杂现实，似乎暗含某种立场/偏见。你若认同此观点，想必早已指出其谬误。真相是：顺境与逆境存在不同程度的差异，二者皆能“塑造”不同类型的人。(此处暂不讨论男性气质问题，毕竟人人都清楚自己是否算男人。)
或者换个角度重构：若顺境造就懦夫，那么当前那些腐败掌权、吞噬90%财富的富人全是软弱之辈，而社会中的纪律与美德尽在我们这些普通人身上。若能培养超级富豪的能干、责任感、目标意识和利他抱负，或许才算有所建树。
“强烈”与“和所有人一样”不是矛盾吗？假设“强烈”具有某种相对性。若你拥有衡量偏见影响力的绝对标尺，我倒想听听。
这是相对于零偏见而言的，我本意是委婉表达。
文中有“男人”一词，未必指代男性气质。我理解的“强悍男人”更接近“具备强劲职业道德、正直品格且对腐败骗子零容忍的人”，而“软弱男人”则是“毫无职业道德、实为腐败骗子的群体”。
文末引文与老年人抗拒变革毫无关联。
因为引文阐述的论点并非“老年人抗拒变革”，而是“经验者常目睹后辈在不知情中犯下可避免的错误”。
某种程度上确实相关——重复这句话的人永远不会意识到自己正是制造艰难时世的弱者。
> 艰难时世造就强者。强者创造繁荣。繁荣滋生弱者。而弱者又催生艰难时世。
实际情况恰恰相反。
强者通过相互较劲证明实力，从而制造艰难岁月。艰难岁月催生弱者，因为强者在逆境中相互厮杀，最终存活的多是弱者。弱者创造美好时光，他们不再争强好胜，而是专注建设，让世界变得更宜居。在顺境中人口繁衍，种群回归均值，恰好孕育出足够数量的强者开启新一轮循环。
二战是强人制造艰难时期的最后一次。我们早已该迎来新一轮轮回，迹象已然显现。
老家伙对着云原生大吼大叫…
赞同。若有人想在Eclipse里写Java，我们当然欢迎…实在不明白这些对云端咆哮的帖子
知道JavaScript为何如此普及、易用，进而成为通用语言吗？
因为把东西展示在屏幕上曾(至今仍是)简单得愚蠢。
这就是全部原因。问题不在于类型系统或npm之类的东西。关键在于：你可以选择从C/Python/Java起步，在编程生涯的前六个月里对着漆黑的终端打印和查询值(这可能是新手从未接触过的操作)；或者选择HTML/CSS/JavaScript路线，从第一天起就能在屏幕上展示动态效果给朋友看。
一切都源于这种人性化体验。Electron能成为UI开发工具，正是因为基于浏览器的UI开发比原生应用更具普适性、更简便且更利于创意发挥——尤其当JavaScript是你母语时，原因如前所述。
行业未能适应终端已不再是计算机用户主流场景的事实，而网络默认填补了这一空白。
此外，React正是应对手机、平板、智能电视等非桌面形态设备爆发式增长的解决方案。你不能再假设HTML能适配所有场景，因此需要一套通用API供移动应用、电视应用、平板应用调用…React让网页成为众多使用该API的应用之一，而非特殊存在。这个理念在当时的背景下具有合理性。
> 将内容呈现于屏幕本是(至今仍是)极其简单的操作。
这正是HTML至今仍是构建UI的优秀语言的原因，也是Visual Basic在90年代初大获成功的原因：将UI组件拖拽到面板上，编写点击回调函数，保存并分发exe文件即可。几乎人人都能上手。
而React及其同类框架则复杂得多。
我认为人类文明在2000年1月1日达到顶峰。数十年前IBM 360系列引发的“向后兼容性”突变，已将全球基础设施中积压的压力释放殆尽。
当时Windows 2000作为服务器操作系统，在桌面端运行流畅。Visual Basic 6(VB6)和Borland Delphi都支持拖拽式图形界面开发。Microsoft Office Professional不仅兼容VB6的大部分功能，还能管理电子表格、数据库及其他文档。
任何非计算机领域的专业人士，只需投入时间就能构建出相当不错的应用程序来辅助工作，而且它确实能正常运行。若需扩展规模，再请专业人士优化细节、提升速度和可靠性即可。
当时几乎所有功能都有文档支持——无论是印刷版还是电子版，几乎每个函数都配有可运行的示例代码。
那是在.NET风潮席卷一切、强行将网页嵌入所有场景之前的时代。
它当然并非完美…当时尚未普及版本控制系统，没有Mercurial或GIT，大多是存放在软盘上的编号PKzip压缩包。
时至今日我们仍未拥有可靠安全的操作系统，我认为这个窗口期已然错过。Genode曾是我的希望，但它至今仍只是组件集合而非日常驱动系统。
BASIC让屏幕呈现变得更简单。我们用过这样的命令：
在Apple BASIC中：
– HPLOT x, y
– HPLOT x1, y1 TO x2, y2
在MS-DOS的QuickBASIC中：
– PSET (x, y), color
反观HTML，我完全不觉得它“傻得简单”。
> 行业未能适应终端已不再是计算机用户现实的现状
我仍在等待基于GUI的终端出现
我想在Scratch里调用git！
Jupyter笔记本界面本质上就是基于GUI的REPL/终端。
你的评论出现在这篇帖子上真是讽刺。早在1980年代末，我们通过NeXT的界面构建器(后在Mac OS X延续)就拥有更优越的版本。DOS和Windows平台也存在类似工具。
你只需在所见即所得的界面中拖拽连接代码，首日就能实现功能。
这甚至比网页开发更简单，因为你布局的是集代码、界面和行为于一体的完整组件。至今网页技术仍未能完全赶上这种水平。
看到这类评论时，我更能理解老一辈为何对年轻人气愤不已——他们重新发明轮子却做得糟糕透顶，只因不懂历史积淀。
>早在1980年代末的NeXT系统(及后来的Mac OS X)中，我们就有更优秀的界面构建工具
我并不否认，只是当我们这代人2005年前后开始学习编程时，它尚未成为入门选项。即便存在，作为初学者也难以接触到如此小众的技术。
我也不算通过JS入门的编程世代，我更早走的是控制台路线。但后来看到朋友们接触编程时，很清楚为什么JS会成为主流选择。
2006年，界面构建器仍是开发Mac应用的标准方式，经过改进后，它至今仍是构建Mac和iOS应用的标准工具(不过现在我们还有SwiftUI)。
有道理，但2006年对新手而言Mac有多普及？
至少在我所在的圈子里几乎绝迹。我第一次接触macOS是2012年，当时在PC上安装的——靠着论坛里某个东欧网友的帮助，才把电脑改造成黑苹果。
微软彻底破坏了所有这些工具，还开发了专属工具——这些工具永远无法在竞争对手的操作系统上运行。
若想找人发泄不满，不妨试试全球各地的市场保护机构。
微软始终未将Access移植到网页和移动应用，这在我看来是个重大失误。尽管存在缺陷，它作为拖放式编辑器几乎能让任何人构建支撑中型企业的简易应用。
看着比我晚十年入行的人谈论“我年轻时”，真是令人毛骨悚然 😀
编程最令人兴奋的时刻，是当你还能畅想那些不可思议的事物——比如拥有256色屏幕，或是运行速度堪比机器码的BASIC(ACORN ARCHIMEDES)，又或是想象一台足以播放视频、甚至能存储完整视频的强大计算机！
2400bps！每天查一次邮件
如今一切成真。我的屏幕拥有1600万色却浑然不觉，12核处理器配64GB内存，光纤网络畅通无阻。那个令人心潮澎湃的未来已然降临。当年那篇关于面向对象编程的开阔视野的字节文章，如今我们已然看清它并非万能解药。
如今有两大问题——世间再无独创之事。你无法创造差异，因为任何你能想到的举动都已被他人先行……当然还有人工智能，它虽有趣却威胁着让我们变得更加无用。
我实在无法重拾昔日的激情——或许只是因为年老力衰罢了。
> 每日仅查阅一次邮件
讽刺的是，这恰是我当下重拾的习惯。多年前因需处理十余个系统的通知，我关闭了所有邮件提醒。如今每日最多查阅数次邮件，仅此而已。若必须时刻关注邮件，我根本无法工作。如今大家工作用Slack、私聊用WhatsApp，邮件已无紧迫性。我虽也在Slack上，但WhatsApp已静音，手机锁屏界面更不允许任何通知弹出。
你用“2400bps”而非“2400波特”真让我失望。:/
每当看到人们怀念旧时光总让我惊讶。没错，那时似乎更简单，但那是因为能做的事太少。
我至今仍怀念当年用300波特调制解调器尝试连接GeoLink的经历——直到父母发现长途电话费用高得离谱，最终退掉了设备。当时固然失望，但没过多久56k调制解调器问世，本地无限流量网络服务也出现了。如今这段往事反倒成了趣闻。
不过当时的挫败感与如今如出一辙，只是缘由不同。变革永存，这本是好事。
我认同如今更难留下印记的感受，但实际难度未必增加。世间仍有无数令人心驰神往的创意等待实现。就在昨天，我发现了Strudel音乐编程语言，还观看了用它创作迷幻音乐的精彩视频。而这类发现如今正以 持续不断的 速度涌现，三十年前这可是相当罕见的。
我们已进入这样一个时代：只要付出足够努力， 任何人 都能制作游戏、应用、网页等。工具如此简便，教程如此丰富且 免费 ，真正阻碍的只有努力程度而非技术门槛。
多年来我每月都会感叹“我们正生活在未来”。当今世界的成就实在令人惊叹。
> 是的，过去看似简单，但那是因为能做的事更少。
更因为计算技术尚未成熟，整体仍是新兴领域。倘若计算机技术停滞500年，永远固守在1980年的水平，我敢断言编程将变得愈发复杂——只为在资源匮乏中实现更多功能。
> 你说“2400bps”而非“2400波特”让我很失望。:/
哈哈 🙂 当时当然是2400波特率，我们用的是FidoNET——在津巴布韦那会儿这可是超级刺激的事。有时得花十分钟才能听到拨号音，但一旦连上看到数据传入的瞬间简直像魔法。国际电话贵得离谱，和海外兄弟通话每月顶多一两次。要是用电子邮件，想聊多久都能聊。
当时的限制在于信息匮乏——没有互联网，没有手册，没有文档。我编写了一个文本编辑器，竭尽所能通过巧妙方案提升速度，但屏幕始终闪烁不止。多年后在南非大学，一位朋友随口提到图形内存速度慢，因此最佳方案是先写入普通内存，再用REP MOVSB指令复制到图形内存。听闻此言我当场破口大骂，质问他怎么知道的？！原来他身处更现代化的国家，能买到专业书籍。如今若你愿意，在刚果也能成为Linux内核程序员。
感谢分享这段回忆。我当年还是个小毛头时，用的可是300波特调制解调器。升级到1200波特调制解调器时，当时的时代思潮认为这纯粹是盗版工具——那些按分钟收费的人总说，除了盗版者谁还需要这么大带宽？信息流通并不自由，资源丰富的国家更容易垄断信息传播。在HTTP和万维网出现之前，信息架构也几乎不存在。
但令我欣慰的是——在地球的另一端，同样有普通的孩子们插上调制解调器，彼此相连，共同探索未来的边界。
从无网时代到仅限职场的网络，再到家用的56k调制解调器、DSL宽带，直至光纤网络。这段历程足以载入一生。
对我而言，从1978年手工焊接的NASCOM-1套件(2MHz Z80处理器，1KB用户内存+1KB显示内存)，到如今亲手组装的十年机龄塔式主机(搭载酷睿i7-5930K处理器)。
2MHz 8位机 → 3.5GHz 64位多核CPU
1KB → 32GB内存(容量暴增3200万倍！！)
磁带存储 → 4TB硬盘
16×48字符显示屏 → GTX 980 Ti 2560×1600显卡 (+6万亿次浮点运算)
离线接入 -> 9600波特率BBS -> 1Gbps光纤网络
从纸上手工编译(或直接将记忆中的十六进制指令写入内存)，到通过语音指令编程“给我写个实现xxx功能的应用”，再到用iPhone与Gemini对话(在1978年这简直像外星遗物)，几乎能询问任何问题。
未来五十年将带来什么？会像NASCOM-1到iPhone+Gemini这般惊人吗？我曾如此认为，五十年后人类级通用人工智能理应问世，但体验会截然不同吗？
我曾在300波特速率的Compuserve上玩《英国传奇》，还开发过一款90年代末风靡全球的CNET五星级软件。
别踩我草坪！
没错，那套从…2010年…就开始的“我年轻时”老调也让我陷入沉思。
这不只是你老了倦了的问题。技术改进的边际效益正在递减。
以音效为例：从“无声”到“有声”是巨大飞跃。从单调蜂鸣声到IBM PC音效是实质性飞跃。CD音质是实质性飞跃。但从CD音质到1MHz采样率的64位样本？无聊透顶。没人会在意。这种改进连引起兴趣都不够格。
我的带宽足够宽。屏幕分辨率足够高。内存足够大，CPU速度够快，免费编程语言够好，数据资源也足够丰富。
问题在于，所有能轻松实现的改进都已完成。剩下的都是些索然无味的任务。
(我认为这种状态不会永久持续。终将出现某种突破——新范式、新语言、新数据类型，总之会开启无数新可能，届时一切又将变得精彩纷呈。)
> 我2010年开始第一份全职工作。我们用Java编程…
我1992年开始第一份全职工作。我们这儿用C语言编程，偶尔想标新立异就用C++。当所有人同时使用时，Sparc 10确实会有点卡顿，不过我有一整架O'Reilly的X Window系统书籍可供查阅。伦敦的同事寄来一张QIC磁带，里面装着名为“gcc”的东西：听起来很刺激，但安装前得先找个空闲日更新SunOS系统。
说实话，这套2010年的编程环境简直令人惊叹…迫不及待想体验了。语言工具都这么棒，再也不用在emacs里手动编辑makefile，也不用在gdb里费力调试了。打赌他们现在连sourcesafe都用不上了。
我估计到2025年他们就会拥有神级配置：速度飞快、稳定可靠的硬件，内存和存储空间多到用不完；强大的开发与协作工具；无需跑去隔壁楼找人就能轻松获取答案的多种途径。而且其中大部分基本免费！真好奇他们面对如此强大的开发能力会作何感想，是否还会继续使用X终端。
我来就是想说类似的话。
自90年代初(我入行之时)起，编程已历经数次变革，而当时我便觉得它在90年代已蜕变多次(尤其与老派大型机或COBOL程序员交流时)。
如今它正经历新一轮变革，这个过程充满阵痛。无人知晓未来会怎样。
> 有趣的是，当时所有程序的运行速度都和现在差不多。
实际上，若以我当时使用宽带网络的优质PC体验而言，一切都快得多。记得曾在此处看过一段视频：有人启动了2000年代的电脑，演示了包括Visual Studio在内的所有软件如何流畅运行。但如今在YouTube搜索时，系统忽略了大部分关键词，只返回一堆“如何加速电脑”的垃圾内容。书签里也找不到那段视频了。唉。
> “记得在这里看过一个视频，有人真的启动了2000年代的电脑，展示了包括Visual Studio在内的所有操作都多么流畅”
是这个吗？Casey Muratori痛斥Visual Studio调试器迟缓，并展示了20年前单核奔腾4上Visual Studio启动和调试更快的视频——https://youtu.be/GC-0tCy4P1U?t=2160
还是这个？罗杰·克拉克在Windows 2000上用C++开发记事本时，评论Visual Studio启动速度有多快：https://youtu.be/Z2b-a4r7hro?t=491
> 我记得在这里看过一段视频，有人真的启动了2000年代的电脑，展示了当时系统运行多么流畅…
你指的是这个吗？：https://jmmv.dev/2023/06/fast-machines-slow-machines.html
注意观察：当前选中的窗口及窗口内选中的项目都清晰可见。微软简直是彻底迷失方向了。
哇，这篇文章太精彩了，感谢分享。有趣的是它已经开始崩溃了——全是那些链接和广告追踪造成的，这又是一种腐朽。
使用Linux/KDE系统。切换到SSD带来的所有优势都得以保留。即使在n100处理器上，一切操作也瞬间完成。只有编译、游戏或重度多媒体处理(比如我相机输出的200Mbps 4k60视频——由于采用4:2:2色度采样，多数处理器无法加速这类视频)才需要更强大的配置。
Xfce或LXQt也是绝佳选择，即便在15年前的老硬件上运行也迅如闪电。旧硬件处理基础网页浏览和多媒体(如播放现代编解码器视频)可能较慢，但其他底层应用完全没问题。
> 使用Linux/KDE
我正在使用。虽非完美无缺，但目前它是最不糟糕的解决方案。
我记不清桌面应用的运行速度，但记得2000年代使用网页的经历。网站加载时会明显卡顿，图片从上到下加载需耗费数秒至数分钟。拨号上网时《Runescape》更新要花一小时。
不过我确实记得微软Word这类应用的界面经常卡死。
如今想获得流畅体验，必须严防死守屏蔽所有内容，只选择性放行最基本功能，否则浏览器会被塞满臃肿垃圾。对了，别指望运行JavaScript——网站绝对会滥用它。更可笑的是，这些网站竟厚颜无耻地指认用户是机器人。
许多网站糟糕至极，连静态文本都无法正常显示，除非用户下载它们堆砌的大量JS垃圾代码。
浏览器问题自不必说，即便是原生应用程序的输入延迟也比80、90年代更糟。
https://danluu.com/input-lag/
https://news.ycombinator.com/item?id=25290118
我认为没有Firefox和uBlock Origin，网络已不再宜居。
YouTube正以史无前例的速度沦为垃圾平台。搜索功能形同虚设，短视频功能更将其变成又一台TikTok式的脑内多巴胺机器。
> 又一台TikTok式的脑内多巴胺机器。
你可以对抗这台机器。
您可以在桌面端观看短视频。在桌面浏览器中，当您在订阅标签页(或仍使用首页时)看到短视频时，可右键点击并选择在新标签页中打开。您可以在网址中将“shorts/”替换为“watch?v=”，即可在常规界面加载同一视频。无需滚动页面。
我四十岁开始编程，三十岁左右转为职业开发者。必须说清楚：如今的编程环境 好太多了 (真的好太多)。
我们拥有超级强大的编辑器、功能强大的语言，还有海量可直接下载的库。
当年开发游戏时，光是把精灵贴图放上屏幕就要耗费数月(没错，是数月业余时间)。
至于Java，同样进步巨大：现代语言更完善，工具链更强大，安全机制更复杂但更可靠，JVM持续发力…
如今我们还有Claude。
能活在当下真是太幸福了。
> 我以前写视频游戏时，光是把一个精灵贴图放上屏幕就要花上好几个月(没错，是业余时间里好几个月)。
我不太明白这怎么可能——在DOS系统里明明可以直接把东西复制到帧缓冲区。当时就有Allegro这类库，开箱即用就能提供海量功能：音效/UI/精灵渲染/动画/特效等等。
但即便不用任何外接代码，将精灵复制到屏幕上也不难——读取BMP文件后逐行复制到屏幕即可。
你是想说编程经验有40年吗？“40年”这个表述让我很困惑
还是说你现在60岁，从40岁开始编程，见证了编辑器的发展历程？
我敢肯定他们不是英语母语者。许多语言用“since 40 years”表达我们所说的“for 40 years”。
或者可能是“自从我40岁以来”？
我觉得这是个不幸的笔误…“old” => “ago”？
事情未必总是恶化，有时也会好转。
TypeScript最近邀请用户试用其新编译器，速度提升7-10倍[1]
VS Code虽广受欢迎，但我个人更倾向用Vim编写TypeScript——其运行速度远超Eclipse且资源占用更低。不过得益于VS Code首创的语言服务器协议及其在众多编辑器中的普及，如今也能实现“编写即编译”功能[2]
至于运行时速度： Java曾以传奇般的启动缓慢著称，至今仍是痛点。现代JavaScript运行时经过优化可快速启动。另一方面，Java在吞吐量方面仍独占鳌头，可谓优劣参半。若想在不牺牲太多易用性的前提下获得更佳吞吐量，如今我们有Rust可选，还有大幅改进的C++。(尽管这两种语言的编译时间都极其漫长。)
[1] https://devblogs.microsoft.com/typescript/progress-on-typesc…
[2] 公平地说，内存占用对比不应将Eclipse与Vim本体相提并论，而应与[Vim + coc.nvim + TypeScript编译器]的完整栈进行比较——其中大部分内存消耗来自TypeScript编译器。我不确定这与Eclipse相比如何。但我更关注输入延迟——此时我确实只关注Vim本身，因为所有LSP相关操作都是异步的。
作者写得好像Java被禁用似的。其实那些想找企业Java工作的人，外面多的是烂差事等着他们。我十年前就干过这种活，文章描述的“黄金时代”可没给我留下什么好印象。
避开NPM这场闹剧也很简单：简历里别提JavaScript，离前端开发远点就行。
> 我们还见证了React的崛起，这或许是前端编程史上最惨痛的悲剧(作为一个正在戒除React瘾的粉丝，我如此断言)。
深表赞同。Github(仅举一例)自从转向React后可用性大幅下降。而这个网站显然不需要React——毕竟它在没有React的17年里运转得很好。
这些年来我始终只用Node、Express、Postgres和Sublime，至今仍是快乐的程序员。我努力不去听那些在礁石海岸上歌唱的妖女之声…
Postgres和Sublime用户在此。生活很美好！
> 究竟哪里出了问题？
只是相较2010年，整个行业格局已发生巨变。
在智能手机和平板电脑普及之前，桌面端只需支持Windows系统(如今可能还得兼容macOS)。浏览器无需兼容Safari。无需过多考虑屏幕DPI、宽高比、横竖屏切换或小尺寸屏幕。布局无需自适应。单页应用的需求也不高。那时全球互联网用户数量远少于如今。
这让我想起一篇关于DevOps的类似檄文：
这就是未来 – https://blog.paulbiggar.com/its-the-future/
现在发现这篇竟写于2015年6月——距今已逾十年！天啊
我不确定如今云时代真的更美好…文中写道
我要回归Heroku
而到了2025年，人们依然渴望这样的回归
“完成工作后，我们会创建‘拉取请求’。这是在单一公司内部模拟开源开发的方式——众所周知，这才是唯一可行的工作模式。通常这意味着代码会被下载到另一台计算机上编译，几小时后，某位同事会过来要求修改几个词。修改后，系统会重新构建全部代码，次日该同事才会批准代码合并至主干。”
解决这个问题能大幅提升效率——在每个拉取请求中生成可测试的预览应用。当前的反馈循环严重拖慢开发速度，管理层却总不愿优先优化流程，尽管这拖累了每个项目。建议直接行动，无需请示。
JavaScript是解释型语言：写完即跑，无需构建步骤。
构建流程本是临时措施，用于处理跨浏览器兼容性问题(Grunt之类工具)。人们过度依赖它，如今我们完全不需要了。TypeScript虽强大，却是阻碍回归敏捷生态的主要障碍。
2000年代人们发现混用代码与HTML标签会酿成复杂性恶魔之巢。到2000年代末，当时的工具已解决此问题。我认为JSX是最佳实践的倒退，它让人联想到ASP.NET——只是年轻人没见过ASP.NET才浑然不觉。
我们曾一度认为npm只是过渡方案，期待更符合网络特性的替代方案出现。但这个愿景始终未能实现。
JavaScript本可以成就伟大。
Maven的构想本很出色——为发布包设置高门槛。但搭配由信鸽驱动的搜索框，这意味着你寻找的东西根本不存在。每当遇到特殊需求，你只能手写实现，或找比你聪明的人代劳，最糟糕的是花大价钱从供应商处购买劣质方案。人们总念叨“DSA不适合编程竞赛，何时需要手写哈希表”，但曾经我们确实需要随处手写哈希表。供应链漏洞固然是成本，但产品本身值得这个代价：你只需导入那个该死的包！
我需要一个具备智能范围合并功能的键值映射，它早在2016年就已出现在crates.io供人导入，而Maven Central直到2018年才出现类似工具。在旧时代，要么它存在于Apache Commons库中，要么根本不存在。那真是黄金岁月啊。
我向来偏爱抽象层次可控的编程。如今技术栈堆得如此之高，单凭个人已无法理解其中运作机制。我也怀念标准规范更精简的时代。在医疗领域工作让我深切体会到：标准只会不断累加，永不精简。如今的复杂性已荒谬至极。我并非主张人人都成为裸机汇编专家，但能理解楼主渴望至少在某种程度上掌握核心原理的心情。
若身处不同类型的公司，2025年的编程体验竟能如此迥异，实在令人惊叹。
身为2025年的Java开发者，我们仍在使用Maven，但已升级到远胜Eclipse的IntelliJ，且公司确实雇佣测试人员。
世界并未变糟，只是你被困在错误的技术栈和错误的公司里。
不过我确实认同JS生态圈糟糕透顶——我以前是全职JS开发者(现在偶尔做些前端)，我们公司现在已组建了专门的前端团队。
用Rust编程配合Nix部署管理，比过去的方案好太多了。我提过Helix比Neovim好用多少吗？用JJ做版本控制，用mergiraf解决冲突。我的个人电脑比以往更强大，能以惊人速度完成超棒的工作。
若能做出明智抉择而非追随最低标准的技术，一切都会变得更好且持续进步。
> 我们在“云端”运行K8s集群。这套基于Linux的服务体系并非直接运行在Linux系统上，而是部署在按小时租赁的虚拟机中——其月租成本与直接购置计算机几乎相当。我们这么做是因为如今没人懂得如何连接电脑了。
这个现实每天都在折磨我的思维…“云”绝对是史上最成功的品牌重塑。2005年：‘在互联网上分享数据要非常谨慎’。2025年：“是啊，我把所有东西都扔到云里了”。
我懂。我认同本文大部分观点。但问题是，旧技术从未消失。
若你怀念Java和Maven的时代，它们依然可用(Eclipse和NetBeans也还在！)
若你厌恶Node和NPM，完全可以不用。你完全可以不碰NPM就搞定移动应用、桌面应用，甚至SaaS风格的Web应用(即便用Hanami或Phoenix这类时髦的现代Web框架也行)。
若你不想让团队盲目跟风用JS、NPM和React，那就主动在项目中抵制这种做法。
> 有趣的是，当时所有操作的速度都和现在差不多。
我常思考人类某些特性如何影响我们创造和接受的技术。
例如对人类而言，几秒钟内发生的事情算快，几秒钟内完成的事情则相当快。因此构建步骤等流程往往会潜移默化地接近这些时间尺度。
如今Java尚可使用，但在2013年那简直是噩梦般的调试体验。我宁愿用PHP5也不愿碰Java(除非从零开始开发项目)。自动重构功能也明显更差——毕竟是Java嘛。正是在那个时期我尝试了Scala和Clojure，尽管调试JVM依然是种煎熬(尽可能要避免)，但至少有限的副作用减少了问题。
如果说编程达到过巅峰，那肯定不是在2010年。
> 堪称最糟糕的调试体验。
强烈反对。我并非要说Java调试是 最棒的 ，但：
1. 你能远程调试服务器上运行的代码。
2. 只要执行路径保持在干净代码范围内，你甚至能调试 无法编译的代码 。
3. 修复部分故障代码后继续调试时，调试器会回溯并执行你在调试过程中刚补丁的代码。†
作为从Java 1.0时代起就从事服务器端Java开发的合约顾问，这是我数十年的亲身经历。
当然，这无法说服固执的怀疑者，但我认为这些功能极具吸引力。
†如今我主要用Rust编程，确实乐在其中，但漫长的编译时间和无法运行故障代码这两点，让我格外怀念Java时代。更常遇到的是，2025年的现代调试器总因某些原因无法检查特定变量——这种bug在Java时代从未出现过。
这正是我当时的感受——那是我第一份工作，此后经历的体验都更佳(2019年重拾Java时体验更是天壤之别)。你说得对，它或许并非那个时代最糟的语言，但相较2025年开发者的体验仍显逊色。
关于第1点：我的情况不适用。第2点：此前并不知晓。第3点：确实存在，但仅适用于部分问题，且坦白说Clojure和Scala的实现体验更佳。
我主要从事Hadoop和ETL相关工作，恐怕你无法说服我保持客观。
关于你的†，我认为像dx这样的新型Rust工具最终将支持调试期间的热代码补丁
https://lib.rs/crates/subsecond
(注：该工具由Dioxus创建，但适用于任何Rust项目)
> 2. 只要执行路径始终在干净代码范围内，你甚至能调试无法编译的代码。
在Java里？怎么实现？
比起仅靠终端调试汇编和C语言，调试Java简直是种享受。
我最初的PHP文本编辑器是Komodo Edit，运行极其缓慢，后来众人纷纷转投Sublime Text。VSCode虽比Sublime更慢，却拥有Git和Prettier等业界支持的强大扩展。我的PHP编程生涯从未达到巅峰，事实上我使用的PHP框架网站至今仍在运行，速度依然慢得惊人。
我正在开发一款不占用内存的人工智能编程工具，Electron之外存在超轻量级的替代方案。
这方面我挺中意vibe coding。它纯粹用html css和js就能构建前端界面，这点深得我心。
这显然存在严重局限，但若你厌倦前端框架生态，希望将所有逻辑集中在后端，这便是理想选择。对我而言，后端逻辑更易掌控
致那些被迫接受公司强制方案的同仁们，愿你们安息
天啊这简直是金句。字字句句都是真理。
JavaScript的制胜之道在于成本控制。当今企业追求以更少投入实现更多价值——这本是应有之义，而你仍可自由选择海量技术栈。若将这种架构与大型语言模型结合，在我看来堪称史上最佳组合。
若作者不愿接触NPM和JavaScript生态，大可去写Spring/Boot——这套框架占据了大型企业90%的岗位需求。我不同意所谓“这个世界已消失”的说法…
我觉得自己很幸运，因为我的经历恰恰相反。2009年我用vim写C++开启了第一份正式编程工作。过去五年我用helix写Rust，生活从未如此美好。
编程曾经是探索与设备沟通的最佳方式。如今设备正试图找出与你沟通的最佳方式。
如今的重点在于如何编程让设备监视操控用户，以便企业为股东榨取更多价值。
我的意思是，过去编程更偏底层，抽象化程度更低。那是很久以前的事了。
对你而言是促销，对股东是短期收益，对客户则是体验恶化。
我初学编程时，是在冰冷地下室用C64写代码，连磁盘驱动器都没有。但我们乐在其中…
我们中仍有部分人坚守阵地，用Eclipse编写Java的Maven项目。效果极佳。
此言不虚。我最近上线的音乐推荐网站刻意避开了React/Next等框架——仅用HTML、CSS和原生JS。认知负荷的差异令人震撼。所谓“巅峰”或许与其说是能力提升，不如说是重新发现简单工具往往已足够。
关键在于为任务选择合适的工具。当界面更复杂交互性更强时，原生项目相较于React的“认知负荷”反而可能更大。
同感。我只用老派的HTML、PHP、CSS和JS为本地企业建站。虽然算不上“云端级”，但稳定可靠，停机率极低，亚马逊和Cloudflare最近的故障期间照常运行。
我不求软件征服世界，只要能解决实际问题就心满意足。
说实话，那人该花时间修好自己的烂摊子，而不是写博客。
我认为IntelliJ是绝佳的IDE，现代框架用起来很有趣，AI帮我处理那些不想做或必须做的事(比如为他人生成优质的README.md)。
容器技术很棒，我的构建速度很快。
我的初创公司采用HA架构，自愈式交易推送到K8s，所有配置皆在代码中，无需担心备份随机配置文件。
硬件从未如此廉价。非易失性存储器、内存和计算资源皆然。现代笔记本拥有出色的显示屏，运行安静，性能强劲，电池续航持久。
流量？根本不成问题。
Websphere当年是个功能糟糕的庞然大物。记得当年所有JEE服务器启动时间终于从数分钟缩短到几秒钟。内存价格终于降到足够低，本地就能同时运行Eclipse和Web服务器了。
Java代码冗长，比现在冗长得多。
JQuery无处不在。
呕
真相炸弹
我这人虽年轻，内心却是个老顽固，用C语言写固件，用C++写应用(纯粹为了Qt！)，看透当今编程界的种种弊端。而那些新人总追问：为什么不用JavaScript做？这样就能上移动端了啊(我们确实用了，只是换了框架——React永远满足不了我们的需求)。要在所有平台实现视觉一致性，不过是付出点“努力”罢了)。这小子还总想用邮件群组安排喝酒聚会，而不是当面问一句——明明我们都在这间狭小的办公室里。部署问题也如出一辙：他喊着要GitHub(才不需要，私有Git服务器就够了)，要AWS，还惊呼什么“npm攻击”？
有时他似乎在进步，但转眼又沉溺于GPT，让人觉得一切努力都白费。兄弟，这太疯狂了——我刚删了2000行代码，他却面不改色，我挑眉追问有多少模块根本就不该存在，结果他若无其事地回答。
问题在于，GPT之流会乐此不疲地给项目添乱。兄弟，相信我，我们必须优先规划所有可能的功能，而不是先测试基础功能再逐步扩展——毕竟我们只有两个需求， 所以本来两周能完成的事拖了两个月，不是因为我经验更丰富，而是我们该照我说的做，而不是讨论那个人工智能经理提出的狗屁建议——真希望我有权直接把它踢出我们的网络。
我和那位初级程序员年龄相仿，只是人生轨迹迥异才走上编程之路
所以当jQuery称霸时JavaScript很棒？…
十五年前的编程体验好得多，除了那些糟心部分。
想到要从TS转回Java就让我心生恐惧
这段直接存进我的搞笑文件夹
> 我热爱编写JavaScript，也欣喜它能在服务器端运行。但这绝不意味着我认为它适用于所有场景。
JavaScript编程已达巅峰。
换言之，你的云成本将降低十倍，这正是你的竞争优势所在。
十年经验带来的就是这样的成果，何必抱怨？
将企业级Java开发定义为基于Eclipse的SVN时代，在我看来简直是妄想。
> 更有趣的是：它从未崩溃，因为开发者技艺精湛，因为系统未被过度压榨，更因为我们时刻保持监控。
行吧，你这么说也行…
我压根不碰第一部分那些破玩意儿。
等着瞧他发现Vercel和Next.js时会怎样。
这些工具如今简直鸡肋。只要有Claude和esbuild，几乎什么都能搞定。
抱着这种思维过日子，人生该有多无趣啊
> 最流行的当属“VS Code”，渲染文本只需几GB内存。
> 我们用过Eclipse，它和VS Code有点像。
这让我笑出声。若你认为Eclipse在任何方面都优于VS Code，那你绝不可能是个认真的人。
我的记忆力虽不佳，但有一件事我至今记得清清楚楚——Eclipse多么臃肿又吃内存，简直难以使用。
老家伙冲着云大喊大叫
如今我享受编程世界的某些方面，尤其与1997年左右刚入行时相比。
我最初在Windows平台用C++开发，使用MFC框架，后来Visual Basic 5.0发布时也尝试过。VB让我眼球都要流血，但很多人对它怀有怀旧情结。Visual C++虽不讨喜，却拥有大量用户。那段岁月让我初尝微软“升级轮回”的滋味：刚让你熟悉某项技术，数月后便弃之不用，转而大力推广新事物。刚适应MFC，他们就推ATL，接着是.NET等等。说真的，那些安于现状从不升级的人反而过得更自在。
我险些错过编程界厚重手册的年代——那时几乎找不到在线资源解惑。Turbo Pascal用户和早期Mac用户对此记忆犹新。而我们拥有的是庞大的在线帮助文件(CHM)和Altavista这类搜索引擎，代码示例却寥若晨星。我们常耗费大量时间琢磨如何施展正确的咒语来实现目标。存在一条“幸福路径”——比如用MFC反复构建完全相同的应用程序。但若想稍作创新，就会踏上艰难之路。
后来我接触到Squeak Smalltalk，并将其用于个人探索，因此始终觉得现实世界中缺失了某种东西——而这种缺失后来确实得以弥补。不过独自开发Squeak的乐趣仅限于不感到厌倦，且无需处理Squeak运行速度无法应对的任务。
和作者一样，我也热衷于结对编程(确切说是极限编程)。我始终不理解反对者的观点——这种协作方式充满乐趣。
我向来不喜欢微软生态，因此对Java的到来充满热情。IBM大力支持Linux平台，众多优质应用正等待开发。虽然初期经历阵痛，但很快便进入高效生产阶段。此期间，智能感知等技术日趋普及，重构浏览器已然问世(最初为Smalltalk开发，后基本应用于Java)。IntelliJ IDEA发布时堪称革命性突破——此前IDE都算不上真正成熟，直到它们追赶上IDEA的开发者支持水平。
我意识到专业程序员这条路不适合我，因为我不喜欢参与项目开发，于是重返校园，最终成为了一名兽医。我的职业生涯至此便告一段落。
我热爱编程，但作为业余程序员，很难持续投入某个项目，隔几个月再回来继续。代码似乎总在退化——曾经能编译通过的代码如今却行不通了。库的用法会发生根本性变化。若你曾在钩子出现前启动过React项目，定能体会我的意思。当然，不用钩子照样能实现功能，但没人这么做，你只能独自摸索。
人工智能的价值在于，它极大简化了探索与问题解决过程，甚至能帮助我理解数月前的编程思路。我身边没有搭档进行结对编程，但人工智能让我更轻松地扮演“非主导程序员”的角色。我欣赏这种特性，相信它能为领域带来积极影响。主要风险在于大型语言模型对未来事物处理能力有限。一旦超出训练范围，它们就会犯下诸多恼人的错误。例如Debian Bookworm与Trixie版本存在差异，而Claude目前对Trixie的操作仍显生疏。它甚至认为Python最新版本仍是3.11之类的老版本。使用LLM时必须习惯处理过时的代码。但对多数人而言，这并非问题。
这是稻草人式的反乌托邦论调。只需继续践行古老的智慧，成为你期望世界呈现的模样。纵使他人如旅鼠般集体跳崖，你亦不必追随。
这简直是陈词滥调的翻版——“现代互联网糟透了，旧时代的网站才更美好！”这种论调在此类讨论中屡见不鲜。
你依然可以沿用旧式编程方式，就像仍能搭建传统网站。没人强迫你使用AI、VS Code甚至JavaScript。
当然职场中你可能没有这些选择权，但这完全不同——你领薪水是为雇主创造价值，而非做自己喜欢的事。
玩得开心。