沉疴用猛药,乱世需重典

609177738

本人还是很看好中文编程的, 奈何火山走歪了还看不到希望, 前段时间也算是弃坑了,但也不时会关注下论坛...
一个PC封装级用户的观点:

1.1 火山IDE 预期实现的 跨语言的火山级代码语法统一:
在未开发GO子平台之前,  安卓和PC 勉强算是实现了90%的效果,结果就是万物基于类以及PC基于C++的语法和特性遭到了大量的阉割.当时虽然吐槽呼声很多,但也还是温和状态.  
在论坛一小众预期商业开发又无较高原始编程能力的人窜说下GO怎么怎么好, GO推出了(此时PC各种缺点及许诺的改善/接口/插件等不得不无期限推后),  结果受制于语法统一, (本人不了解GO,据他们说)多返回值等重要特性被阉割了,紧接着这部分人也开始吐槽.
现在进行时, 由于AI的飞速发展, 又一部分人又窜说开发H5 PY等等, 即便开发了, 也一定会有大量阉割, 你们也一定不会满意的.

1.2 万物基于类
万物基于类即面向对象开发不是不好, 但是为了语法统一而实现的万物基于类对于PC来说就是就是错误的决策,   典型"代表作品" 就是结构体(挨了多少骂才弄了个别名类型,而且还改了又改)

小结:  个人认为, 跨语言实现火山级语法统一就是一个错误的决策.   为什么会有那么多种编程语言?  不外乎为了低代码,高安全.这么多编程语言的语法特性就一定千姿百态. 如果这么多编程语言语法相似,就不会推出这么多的编程语言!  想通过二次包装实现统一, 就一定存在阉割和一些诟病, 不可能避免.   



2. PC的问题

2.1 翻译机制的不合理
PC太多翻译代码已经固定死在IDE程序中, 典型的例子就是 万物基于类的虚函数,  还有嵌入文本的宽字符宏 _CT  (详见论坛某贴加入SDK头文件报错), 为什么不定义一个火山自己的宏,比如_VCT _VT 等等?   还有其他的一些函数就不一一举例了.  用户想实现一些扩展功能都受制于IDE无能为力.

2.2 界面设计器接口
在封装EXDUI界面库时,遇到了很多问题, 最艰难的一条当初已经与吴总沟通后修改了. 还有一些是许诺后期开放插件接口(论坛帖子有说),也遥遥无期.
在选择夹三改后,开发EXDUI时发现了吴总的任性, 接口必须支持HWND句柄,沟通后也没有解决(后另辟蹊径不完美的解决), 即便不开放IDE级插件,难道不能单独给设计器开放更多的设计器组件函数操作接口?


3. 关于论坛许多人的观点.
有的很激进,有的很保守,有的赞同 ,有的反对.   吴总的个签是 让所有人都能写程序, 因为那个时代的青年中年外语水平整体偏低,中文编程的易语言加之拖放式界面响应非常简单,可以说非常成功!   
现在在论坛叫的最积极的我猜大多数都是"商人",我不觉得他们有错,但是他们只是看到自己希望的,没有看到整体,  就像我上面 (1)说的.  如果没有(1)这个问题, 当初封装的PC 会不会更好, 哪怕是大色他们说的最最初的内测的火山版本,总会比现在的架构更好,   GO 会不会更好?你们希望的多返回值是不是也会实现了呢?  
地基歪了/规划不理想, 楼还能好吗?   
一个子产品的推出完善了吗? 完善到了什么程度?  有多少人力物力 又紧接着想推出更多的子平台? 现有的框架对于多平台合理吗?

如果火山IDE框架合理,即使 官方人力不足, 即使同时推出N个子平台, 也不会影响火山发展的, 还是有很多用爱发电的用户的, 加上AI的配合, 一定会正向积极的促进火山的发展, 而不是现在这样, PC 这边吐槽着, 普通用户难受, 封装用户更难受,  官方还致力于开发GO,  GO这边又开始吐槽, 官方又要开新的子平台. ....


沉疴用猛药,乱世需重典,  这位用户说的我还是挺赞同的.

是表格还是文本,是中文还是英文都不是改革的拦路虎, 总会有办法的.

如果有魄力,我还是非常愿意支持火山的.

言尽于此,   且行且看吧.  

609177738

2025年7月2日 预测一波 未来的更新 , 立帖为证 :
1. 所谓的"在火山视窗里面直接使用js和python代码,这比搞c++代码自动封装容易一些" 不会推倒 "跨语言"语法统一的框架,  基本上仍是在原有的底子上堆叠.   C++是一门 面对过程+面对对象的编程语言,而不是单一的程序设计思想, 不应以类的实现方式来以偏概全的阉割.

2.要是按字面意思实现 "在火山视窗里面直接使用js和python代码"(这个是前提),  那就相当于 "画蛇添足"的表象,  脱离了目前PC的C++,  等同于视窗用浏览器组件进行各种嵌套功能和界面, 这个早就实现了, 但是实际上有多少人用浏览器来实现自绘界面库了呢? 更多的呼声仍是开发新的自绘界面库!!!  
怎么说呢 ? 可能方便了哪些C++什么都不懂的小白,可以快速实现某些js或py的库的功能, 如果不可避免的遇到真正的C++代码和c++库 ,其封装难度和效率仍不会得到解决.

3. PC的 操作符/ 参考/指针  仍不会实现.  插件的开放仍遥遥无期.

诗木

论坛很多建议是非常好的，吴总对这些建议一般是已读不回，只有他自己在封装新东西时遇到类似的问题才会解决，他觉得没问题那就是你怎么说都没用。。。

kingsoft

我应该是最早建议官方AI封库的！也不知道是实现不了还是为啥！常规做法，是一个平台做起来了，顺势挖掘细分的子平台！现在的火山就向下围棋，估计除了棋手，所有人都看不懂火山要做什么，准备怎么做！
所以我觉得没有啥好说的了！不用指导不用建议，估计是论坛没有人qi了，官方搞个讨论来聊聊各位！
发的建议会不会采纳也不公布！就是让用户猜！多搞几次，不知道还有没有人会出来发表真实意见了！
哎，火山，火山，喷发一下就熄火了。。。。名字就没有取好。。。。

shuimiao

确实是多子平台统一语法这个策略是错误，导致强行对齐，就会丢失每种语言的各种特性和无限可能，并且最终也无法做到每种语法统一，只是四不像。中文编程用户不是不会编程，只是母语受限而已，所以你强行统一实际没有统一的语法对用户帮助不大，反而极大限制了每个子平台的前途。让每个平台在表格编程统领下实现各自语法的完美兼容（支持直接调用原生代码），使用别名方式映射英文类库为中文这样封库就是轻而易举。当然当初做决策肯定是有局限性的，看不到未来趋势和情况，这也没办法

hcwanz

shuimiao 发表于 2025-6-30 21:36
确实是多子平台统一语法这个策略是错误，导致强行对齐，就会丢失每种语言的各种特性和无限可能，并且最终也 ...

成本是个问题, 每个平台写不同的语法, 那光是"语法分析前端"就写不过来了, 火山的开发成本就很高了.


其实从更新也能看出来, 火山大部分语法更新都是用@属性解决的, 我猜就是@属性比较好实现.

南湾

大佬说的对

中發白

还有一个问题比较严重,培育新生力量,好的教程少,教学机制少,只有引导新生力量不断补充,不断成长,不断状大,火山的生态才能起来

hjh2112

shuimiao 发表于 2025-6-30 21:36
确实是多子平台统一语法这个策略是错误，导致强行对齐，就会丢失每种语言的各种特性和无限可能，并且最终也 ...

你行你上呀，这错那错的。按你说的做，你又得说怎么四个子平台搞了四种语法，真的如你所说四不像，每个平台的语法都得重新学，这个平台搞一套，那个平台搞一套，开发时候全乱套了。

hrq520

吴涛大佬真的别再为了那点点便利，阉割语言了，可以想想办法在完全支持原生的基础上，做一些便利小白操作的功能就好啊，欸  火山是火山，别再用易语言的思维做了啊！！说爱你真的不容易啊------火山！！现在掉头重写火山都好啊，树挪死，人挪活。。真的不想看着火山背靠吴涛大佬，最终走向没落

amwji

你以为容易这几天论坛全是讨伐老吴的，估计老吴也苦