本人还是很看好中文编程的, 奈何火山走歪了还看不到希望, 前段时间也算是弃坑了,但也不时会关注下论坛...
一个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这边又开始吐槽, 官方又要开新的子平台. ....
沉疴用猛药,乱世需重典, 这位用户说的我还是挺赞同的.
是表格还是文本,是中文还是英文都不是改革的拦路虎, 总会有办法的.
如果有魄力,我还是非常愿意支持火山的.
言尽于此, 且行且看吧.
|