沉疴用猛药,乱世需重典

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的 操作符/ 参考/指针  仍不会实现.  插件的开放仍遥遥无期.

VIsualC8

你的提议重要吗？
某人自从e语言开始 沉迷自己不能自拔
你说的很好，但是别说了

dengzf

从最初的禁止复制出来代码就注定了现在的结果........所谓pc的限制,全部来自当初防他人用火山的代码就注定了...根源是在防止它用火山的c++源码,才设计更改成了现在这种继承obj

理性看待,能用就用吧,不要有太多的期待

Morning

609177738 发表于 2025-7-2 23:29
2025年7月2日 预测一波 未来的更新 , 立帖为证 :
1. 所谓的"在火山视窗里面直接使用js和python代码,这比搞c ...

支持

cxz7411

个人认为火山pc应直接简单的支持c++库的引入和使用,最重要的是兼容性和引入的简便易用性,这样庞大的各种c++库使火山不必再去自己封库,再好一些的话就是尽量放开ide的接口,使ide的各种改造和完善由官方和民间共同完成.这样火山ide一劳永逸,不必再去自己造各种轮子.

高山！＆流水

其实在基于表格编程的基础上完全原生汉化也不是不可以，可以学习Delphi ，原来delphi只支持windows，通过逐步扩展框架，现在几乎全平台了，

朕的

amwji 发表于 2025-7-1 11:33
你以为容易这几天论坛全是讨伐老吴的，估计老吴也苦

如果连人看都不看他一眼，说都懒得说 那才是无药可救的时候

liuzhichao03

你这样的级别提的东西吴总都不重视，那我们这些人的帖子“已读不回”就没啥可说的了。

amwji

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