递归火山软件开发平台

标题: 沉疴用猛药,乱世需重典 [打印本页]

作者: 609177738 时间: 2025-6-30 20:26
标题: 沉疴用猛药,乱世需重典
本人还是很看好中文编程的, 奈何火山走歪了还看不到希望, 前段时间也算是弃坑了,但也不时会关注下论坛...
一个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这边又开始吐槽, 官方又要开新的子平台. ....

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

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

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

言尽于此, 且行且看吧.

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

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

作者: shuimiao 时间: 2025-6-30 21:36
本帖最后由 shuimiao 于 2025-6-30 21:37 编辑

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

作者: hcwanz 时间: 2025-7-1 07:08
本帖最后由 hcwanz 于 2025-7-1 07:21 编辑

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

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

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

作者: 南湾 时间: 2025-7-1 07:23
大佬说的对

作者: 中發白 时间: 2025-7-1 07:38
还有一个问题比较严重,培育新生力量,好的教程少,教学机制少,只有引导新生力量不断补充,不断成长,不断状大,火山的生态才能起来

作者: hjh2112 时间: 2025-7-1 08:47
本帖最后由 hjh2112 于 2025-7-1 08:48 编辑

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

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

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

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

作者: liuzhichao03 时间: 2025-7-1 11:33
你这样的级别提的东西吴总都不重视，那我们这些人的帖子“已读不回”就没啥可说的了。

作者: 朕的 时间: 2025-7-1 18:04

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

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

作者: 高山！＆流水 时间: 2025-7-2 00:49
其实在基于表格编程的基础上完全原生汉化也不是不可以，可以学习Delphi ，原来delphi只支持windows，通过逐步扩展框架，现在几乎全平台了，

作者: 609177738 时间: 2025-7-2 23:29
本帖最后由 609177738 于 2025-7-2 23:31 编辑

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

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

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

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

作者: Morning 时间: 2025-7-3 10:09

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

支持

作者: dengzf 时间: 2025-7-3 11:50
本帖最后由 dengzf 于 2025-7-3 14:23 编辑

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

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

作者: VIsualC8 时间: 2025-7-3 15:12
你的提议重要吗？
某人自从e语言开始沉迷自己不能自拔
你说的很好，但是别说了

作者: 绯陌如夏 时间: 2025-7-4 21:10
熟悉: 别再阉割了
新手:咋这么难,就不能学学易语言,你这样人都走光了巴拉巴拉吧~~~~~~~

作者: numbersir 时间: 2025-7-5 11:29
不知道一个IDE支持所有语言特性市面有没有？
没有的话要不这样吧，视窗的C++语法特性全支持另搞个独立的IDE，也许方便嵌入原生、封库也方便AI辅Zhu，其他子平台的可精简语法统一行不行？

作者: xuwanbin 时间: 2025-7-7 13:54
使用了一下go,发现语法虽然不一样,勉强能看懂,但是出问题找AI的时候AI看不懂火山的语法啊,让AI写了一个原生的,发现也能看懂,所以go的开发意义一点没用,原生的更简洁易懂

作者: Morning 时间: 昨天 13:51
火山需要你哥哥

作者: xmr182108 时间: 10 小时前
:噜阿噜把易语言升级了就行了

欢迎光临递归火山软件开发平台 (https://bbs.eyuyan.com/)