火山中文开发-吃了时代红利的流氓生产器
立场声明
这篇文章酝酿了许久，本来不想写得这么愤青，但最近看到的一些言论实在忍无可忍。所以，我承认，本文的用词比较极端，打击面有点宽，逻辑也有点乱，不喜欢就关闭不送。
这里只从开发者与用户角度谈技术与产品，不要搁这讲政治与民族。
请不要评论诸如「你行你来」的话，难道批评一个东西之前必须得先做出代替品才行么？
关于转载
本文授权所有平台（包括第三方博客、公众号等）附带原始链接的全文转载。不允许断章取义。
开局暴击
我们先来欣赏一下火山半官方人员的言论。
我承认我对 fastjson 有偏见，但这回复更莫名其妙，洗也不是这么洗的吧。
背景介绍
易语言可以说是中文编程的鼻祖，尽管不支持 64 位，不支持 utf8，绑定 windows（别给我提那个残废的 linux 支持），但至今（2022）依然有相对庞大的开发者群体。
易语言由吴涛一手打造，后因为股权纠纷（疑似）以及架构过时等种种因素，已陷入实质上的停止更新。在这十几年中，吴总相继推出火山游戏开发平台（MMORPG 游戏引擎）与火山开发平台。
前者毫无疑问已经凉透了，保守估计已经发布 5+ 年，未见任何成功案例，其官网 demo 演示仍然需要 flash player。这里不过多讨论这个游戏平台，但从其介绍（我们有理由相信这个介绍是吴总亲笔写的，所以不能甩锅给营销部门）我们可以略窥一二吴总的性格，以及如何影响易语言与火山的发展。
后者已经开发出安卓与视窗子平台（没错，不叫 android/windows，汉化要彻底嘛）。
关于吴涛
「一个成功的程序员，但不是合格的商人」 这不是我的一家之言，而是众多网友，包括一些易语言与火山的支持者共同的看法。从这一点上，我是佩服的。毕竟在 资本主义 市场经济的时代，能坚持自我不被资本与利益绑架，潜心数十年投入一个几乎没人看好的领域，需要莫大的勇气与毅力。
但今天，我不同意这句话。如今私以为，吴涛甚至不能称为成功的程序员了。 别误会，我没有、也没那个资格质疑吴总的技术实力，而是质疑他的技术本身，以及对技术的理解，对趋势的把握是否已经与时代格格不入。举个略有极端的例子，如果一个人能拿汇编，甚至纸带打孔写出产品级别的程序，我必须是佩服的，但不代表这个人与时代适应。再来个其他行业的例子，如果一个人拉黄包车贼溜，知道哪种步法平稳省力，知道如何调节呼吸，我甚至赞同给他个劳动模范，但是，这在当今社会意义不大。
为了保证项目质量,能不使用的外部开源代码绝对不使用,即使必须使用,也必定将其源代码全面通读且测试通过后才会应用到软件中.并且由于是完全由其个人独自开发完成,避免了多人开发中容易出现的协同类问题.
（我们暂且忽略中文使用英文标点的排版问题）
吴总竟然把这两个事情当作优点来宣传：
- 尽量不适用开源代码，除非通读
- 完全个人开发
这两个加起来意味着吴涛一个人搞定了网络、逻辑、渲染等游戏引擎的核心，甚至还只身一人做了优化，这还没算上数据库、日志、路由等细节东西。理性的人应该知道个人崇拜是不好的，也应该知道没有完美的人，还应该知道有些错误是很难自查出来的。 一个人搞定所有不仅仅意味着潜在的 bug，更意味着后继无人。应该没有哪个游戏公司敢用这样一个随时停止维护的产品（打一枪换一炮的赌博小黄游除外）。而吴涛把这样一个巨大的缺点作为优点宣传，可见某种程度上已经与社会需求和技术趋势脱节了。在这种理念的指导下，恐怕火山游戏引擎与后来的开发平台都难逃闭门造车带来的厄运。
时代红利
易语言
易语言赶上的时代红利是显而易见的——国民普遍英语水平低，自学资料匮乏，主流编程语言（那时还是 c++/java/asp）入门困难。我大方地承认，是易语言把我带上了编程的道路，甚至在今天，偶尔还会用易语言写写小工具（它做 UI 真是太方便了）。
有一个观点我特别赞同吴总：编程入门难，难的从来不是那几个关键字，而是背后的英文生态————API 是英文，文档是英文，社区是英文。除了语言之外，难的就是那几个晦涩的概念：赋值(=)与比较(==)、指针、哈希表、数组（尤其是从0开始）。易语言完美解决了所有这些问题。
除了对语法与数据结构的封装，易语言的另一个制胜法宝就是对功能的封装。无论多么复杂的功能，在易语言里很可能就是一行代码的事情。开发者从来不需要关心什么系统 API，什么生命周期什么乱七八糟的，就可以实现（在 windows）上所有需求。
可惜的是，这些红利已经没了。 新一代英语素质已经明显提高，再加上各种翻译软件，高中生直接看国外文档已没有太大障碍（除了心理障碍）。自学资料铺天盖地，哪怕接触不到 Youtube 里优秀的寓教于乐的手把手教程，哪怕是 Bilibi 最粗制滥造的视频也足够入门。主流语言已经形成了完善的中文圈子，各种私人博客、cnblogs、掘金，即使是遍地狗屎💩的 CSDN 也还是有一些可以入目的内容。最后，Python 已经几乎火出圈，从专业的编程语言慢慢演化为大众的工具。各种库数量之多恐怕已经赶超易语言，甚至小百行代码就可以搞出一个 AI。作为脚本语言还自带新手加成，以及跨平台加成。哦对了，还有极其智能+养眼的 IDE。
不过易语言也没有彻底死亡，在个别领域依然散发光芒，比如：
- 外挂
- 中年人的职场/带娃小工具
这些领域要么没有可持续性，要么拿不上台面。因此我觉得可以说，易语言辉煌过，但，它的时代已经过去了。哦，Python 已经纳入部分地区计算机高考，仿佛回到了易语言走入校园的年代。
火山游戏引擎
个人猜测，这个产品也是瞄准了一个时代，那个类传奇/私服遍地开花的时代。
也许是吴总低估了游戏引擎的工作量，产品出来之时端游衰落，政策收紧，游戏引擎胎死腹中。
火山开发平台
私以为，火山平台吃了两个红利，但并没有易语言那么明显。
一是跨平台趋势
火山大打跨平台旗帜，骗来了很多人。结果其只是语法跨平台而已。掌握多个语言的朋友应该非常清楚，换一个语言难的从来不是语法，而是思想、标准库与平台 API。除了极个别奇葩语言外，大概 2 小时足够学会一门新语言的语法了。因此这波红利不是关键。
二是设备性能的提升
这是我想疯狂吐槽的。火山平台故技重施，企图通过封装高级功能来拉低编程门槛。但时代已经变了，这不是之前那个面向过程的简单时代，基本上无脑翻译一下就可以。现在呢？最基本的面向对象继承、多态火山都没完全实现（不支持函数重载），更别提 AOP，函数式，协程，声明式 UI。
这些特性火山没有直接支持，无法（很难）封装过去。于是各路大神各显神通，奇技淫巧层出不穷。最直接的后果就是性能疯狂下降。这当然不是火山一家的问题，所有跨平台框架都牺牲了性能，比如 Electron/Flutter 等。但只有火山在没有原生支持的情况下强行封装，性能损失远超 V8 等 VM。 要不是现在设备性能高，可以让开发者折腾，火山做的的程序恐怕打开就得无响应。
不难看出，火山的「红利」更像是「前提」，他们不能给火山带来发展加成，相反，火山得依赖他们才能生存。火山官方总喜欢把现状甩锅给时间，什么发展时间短啦，人手不足啦。但我看，这个产品本身就不适合这个时代了。你利用这个时代提供的条件得以生存，结果干的还是上个时代的事情。就好像用发动机驱动水车舀水，结果抱怨内燃机效率低，那为啥不直接用水泵呢？？？
流氓生产器
若我呼吁抵制火山平台，这就是最根本的原因。也许火山本身没错，但它惯出了一堆流氓开发者并以此为豪，这就是它的错。
如果说上面的种种影响的最多是火山圈子的开发者，那么这一条影响的是所有用户，所有火山平台支持的系统的用户。我们在不经意间安装火山写出的垃圾软件，要么就是疯狂耗电，要么就是把存储搞的乱七八糟。
说起流氓的成因，大概可以从两个角度入手：使用者和封装者。当然，不管哪种，始作俑者就是火山本身。开发是一个专业技能，即使要大众化，也要有限度，否则就会变的不幸。这就像无人机，大疆把他拉到了消费级，但必须控制住门槛。如果什么牛鬼蛇神都可以人手一个断头机，恐怕我们不穿铠甲都不能出门了。
使用者
火山平台用「跨平台」噱头吸引了用户，再把不同平台的 API 封装成相似的格式，给人一种真的可以跨平台的假象。这种封装高不成低不就。要么就干脆原汁原味地翻译，让开发者先去学习这个平台的特性，再来开发。要么就内建一个抽象层，彻底屏蔽底层差异。现在可好，火山让开发者们以为它已经屏蔽了底层差异，结果遇到问题又甩锅出去：系统限制。
举个例子，因为火山的蛊惑，开发者们误以为自己可以无缝从 Windows 切换到 Android 了。结果咧？有人提问如何保存文件可以在 App 卸载时保留，半官方人员竟然回复「取外部存储空间根目录()」，要不是现在 Android 默认禁掉 SD 卡写入权限并无法随意申请，按照火山这作风，恐怕我们的 SD 卡变成坟场指日可待。
科普时间
Android 有许多目录供 App 使用。对于需要卸载保存的文件，需要根据类别放到 Document/Download 等不同的目录。不允许在 SD 根目录擅自创建文件。
显然，这位开发者完全没有学习 Android 开发理念，把 Windows 那一套（随便找个盘符写文件）套用到 Android 上。 而且这位官方性质的解答人员也并不熟悉现代 Android 开发，其给出的答案仅仅是实现需求，根本不考虑最佳实践，不考虑用户体验。久而久之，火山平台的代码风气可想而知。
类似的例子数不胜数，再比如这个「后台音乐播放的解决方案」(archive)。这位半官方人员开了一个 Service 直接调播放 API 来放音乐，并说：「想要一直后台播放肯定不可能的。。毕竟安卓系统可能会把软件杀掉。」
这可几乎是一个官方性质的 demo 帖子，是给其他人学习的，结果就这样乱说？？
科普时间
Android 用 Service 后台播放肯定被杀。但是 Android 提供了专用的媒体播放框架，其不仅不会被杀，而且还可以自动接入系统统一的媒体控制按钮（比如通知栏控制、蓝牙控制、智能手表控制等）。例如 QQ 音乐，即使我们不给他后台权限，直接划掉，也不会停止播放。这才是后台音乐正确的实现方案。
可惜 Android 市场在大陆审核形同虚设，用户也不了解技术原理，结果就是，用户为了使用 App 被迫给了后台权限，忍受着无法通过蓝牙等设备切歌的屎一般的体验。更惨的是，由于封装不当/使用不当，很可能在后台疯狂消耗电量。
所以，这些不是孤立的问题，火山封装架构有缺陷、官方人员技术不过关、暗示用户无需额外学习就能随意跨平台开发，最终毁的是一整个平台，说火山是「一粒老鼠屎，坏了一锅粥」一点都不过分。
封装者
首先我得先帮封装者辩护一句，某些问题不能怪他们。因为火山本来就存在一些语法不兼容，吴总也要求封装要简单，简单到用户不需要阅读任何文档，只靠两三行的内置注释就能会用。
原话：「要求最终用户通过阅读注释就能掌握对所封装内容的使用方法。」(archive)
这显然是不可能的呀。即使是封装很好的 python，一个 lib 的文档往往也是一整个的网页，吴总居然要求只靠三四行注释用户就会用？
所以封装者普遍的做法是高度隐藏实现细节，忽略错误（比如一个可能抛出 3 种异常的函数最后只返回一个 boolean 作为结果）。 我们知道神奇的二八定律——80% 的代码都是容错处理，只有在 20% 的情况下才会用的到。火山封装的哲学就是——忽略他们！
直接结果是，火山的库在效率和鲁棒性上都大打折扣。而火山开发的 App 又是建立在封装的基础上的，底层的“标准库”几乎没有，最终程序的质量如何可想而知了。
还是举个例子，火山一个著名模块中有一个函数，用于判断服务是否正在运行。其具体实现是获取服务列表，遍历一下看看有没有指定的服务。这个实现本身没有毛病，原生 Android 开发者也经常这么干。问题在于，这种封装隐藏了一个重要细节：这是一个循环操作。 你要说火山不重视性能吧，某些玩家用户还热衷于与主流语言比较，声称什么火山最后会编译成 c++/java，性能无异，满满的自豪感。你要说他重视性能吧，这样高度的封装，调用者对时间复杂度毫无概念，一不小心多套了几层循环，直接爆炸。
类似的问题多如牛毛。例如某一功能的实现需要一个临时变量，如果我们批量操作则可以复用它。但因为火山高度封装，一次操作就是一行代码，已经是最基本的执行单元了。复用？不存在的。什么？你说为什么封装为什么不留一个复用接口？那请问小白还能通过注释就能掌握使用方法吗？
可持续性
吴总倒是大言不惭，列出了火山的几个优势(archive)：
- 系统核心类库全部开源可自行随意更改
- 程序中可以直接使用已有不计其数的C或C++代码资源
- 写的是火山程序，实际上生成的是C++程序，可以与其它C++程序员协同开发;
我们一个个看：
- 更改核心类库？合着压根没考虑兼容性是吧，只能自己一个人开发，甚至只能用一个设备开发，甚至都不打算升级核心类库了。不然改动不就覆盖了么？
- 直接使用。确实可以用 @ 嵌入语法。没有高亮，没有提示，没有 lint，IDE 瞬间变成记事本。
- 可以与其它C++程序员协同开发。你猜专业 c++ 程序员看到拼音命名、没有复用，吞异常的代码会不会吐血？
火山的可持续性发展有严重的问题。吴总估计以为整个技术栈和他本人一样，只会深入，不会发展（火山还使用 MFC 呢），然而事实是，移动开发/web 开发日新月异，别说火山这种需要翻译的库了，就连 java 写的原生库有时候都跟不上 Android 更新的速度。现在火山论坛已经出现了不少帖子，因为 Android 更新导致的 API 失效，未来这种情况会越发严峻。
再加上上述 协程/声明式 等技术（模型）的兴起，火山严重的水土不服。一个闭门造车搞出的产品，在发布的时候就已经落后于时代了，怎么去谈可持续性呢？ 吴总又能有多少钱去雇人不断更新类库呢？其他人无偿贡献的库完全没有保障可言，他不用了可能就不更了，那其他使用者怎么办？
开发者与封装者有一道难以逾越的鸿沟。如果说原生开发者与 lib 开发者是大学和研究生博士的区别，那么火山的开发者与封装者则是哑巴和会说话人的区别。这种区别不能靠短时间突击搞定。因此一个库作者跑路了，那就是真的凉了。
后话
火山也不是一无是处，但它搞错了自己的定位。如今比较流行低代码，火山从这个角度去搞或许还有不错的前景。但非要把自己标榜成“正规军”，你一个依赖其他语言的语言（注意，甚至不像 kotlin 那样编译成字节码，而是翻译成其他语言）非要和主流语言硬刚，哪来的资本与勇气？
产品本身的问题，加上官方团队的故步自封。以及用户群体的傲慢与偏见。你和他们聊技术，就只会什么“卡脖子”什么“民族语言”之类的诡辩。甚至抱怨国家和公司没有眼光，不扶植这么一个优秀的产品。这样的氛围，火山能发展起来真是见了鬼了。
哦对了，至今（2022.8.3）火山都不支持代码复制。 2023 底左右支持了，但分享代码片段还是靠截图和发文件。真的难以想象。
最后，让我回应吴总的一句话来结尾。吴涛在一个讨论国产系统适配、少儿编程和低代码的帖子里(#8)(archive)回复：
都想走捷径,都想吃快餐,都想弯道超车,那硬骨头谁来啃?
（再一次地，我们暂且忽略英文标点的排版问题）
说儿童编程、低代码是快餐我不反对。说易语言的探索算「啃硬骨头」我也不反对。您管一个翻译封装其他语言的框架，甚至连嵌入代码词法分析都没有的软件叫啃硬骨头？？？？？？
如果说易语言对中文编程还有点贡献，我愿说，火山的贡献是零。
就算真要发展中文编程，难道我们要靠一个在 2022 年还认为 https 没有意义、程序有漏洞无所谓的团队？
最最后，如果一个非政治产品，却以政治/民族来宣传自己，那只有一个可能性，就是它没有其他优点值得宣传了。