|
[观点一]放弃表格代码,直接文本代码,这样AI才能支持.
[个人评价]
这种人不是纯就是坏
1.表格作为火山来说是特色,有积木编程,有蓝图节点连线,目的是什么?那就是降低门槛,提升效率,也符合趋势,表格编程本质是 低代码,如今低代码平台已成为行业趋势.
2.将“专业”等同于“必须文本代码”,却忽视了工具的本质是 高效解决问题。无论是积木、蓝图还是表格,形式不同,但核心价值一致——让创造更简单.
3.关于AI对表格的影响,AI + 表格编程 会让开发更高效,尤其适合中小企业、教育、快速原型开发,表格编程AI不支持”是错误观点!AI不仅能支持,还能让它更智能、更高效!这需要时间,需要我们火山全体用户一起努力.
[观点二]
鼓吹AI,弱化中文编程存在的意义
[个人评价]
1.母语编程让代码更易读、易维护,降低团队协作成本
2.提供纯中文的API、文档、调试信息,减少理解障碍,让开发者更专注于业务逻辑,而非语言障碍。
3.AI不是取代中文编程,而是让AI更适配中文用户的需求.
4.不要用几次AI就觉得自己行了,AI是辅Zhu,不是替代,用AI的前提是你要有纠错能力,软件开发是系统工程.
我认为技术应该服务人,而不是让人适应技术.
[观点三]
反对H5子平台开发
[个人评价]
个人认为H5平台很有必要开发,就像吴总说的 这真的是实现火山环境闭环的关键一步,请吴总不要动摇.
因为H5范围太广,我以基于VUE来实现表达下个人观点
1.VUE是渐进式易上手的前端框架,它的核心理念就是响应式数据,组件化开发,这跟火山的易用性天然契合,特别是火山的表格,VUE的模板表格可以表达,CSS样式更别说了,表格更合适,脚本方面,就跟我们平常用的一样展示效果.但他是全中文.
2.基于VUE可以实现跨平台,同时还可以反哺火山PC,火山GO,火山安卓,通过它可以做出精美的混合开发应用.
3.基于VUE如何实现跨平台?Vue 本身就是为 Web 设计的,编译后可直接在浏览器运行,结合现代工具链和跨平台方案可以轻松实现 H5、小程序、桌面端、移动端 等多平台开发
小程序:**/zfb等小程序开发,可以通过编译工具转换市面上的uni-app,Taro都可以实现,这部分官方不需要授权,因为生成的是VUE程序
桌面:用 Electron或Tauri 打包 Vue 项目为桌面应用
鸿蒙应用,未来还可以通过ArkUI 适配
[关于火山]
为什么会有那么多的人怨声载道?不可否认的是,这是火山的问题也是迫切需要解决的问题
本质还是库少,库更新不及时,要知道用火山的用户都是面向库开发,就跟易语言用户都是面向模块开发一样,少了模块啥也不是(话虽难听但是事实,我本人也是这样的),火山用户也是这样的,少了库,啥也不是,库是根基,但火山库封装难度太大,吴总你哪怕需要重构编译器也要解决,不然火山后面随着平台越多,用的越难受,你自己也会很累.
火山库的封装,应该把他优化到普通小白也可以封装,可能有人说,这是不可能的,小白编程都不会还封库,但别忘了,小白会用AI啊,AI生成的代码,他自己修修改改就能封装成库,然后再用火山自己的中文代码语法来调用自己封装的库,这才是AI对于火山最合适的用法.
站在普通用户角度来说,上限更高了,不会被封装语法限制在只能等库,买库的尴尬地位,通过自己和AI配合折腾下,可以实现自己搞库
站在吴总的角度来说,不用花费资金去收一些普通的库冷门的库来满足用户了,可以专注收精致的库来作为官方出品迭代
站在封库的角度来说,封库更简单,但会动你们的蛋糕,找你们封库的用户会大量减少
站在火山平台的角度来说,那些开发的子平台真的可以起飞了,群众的力量是伟大的
[关于投票]
真的不建议发什么投票了,用户的评价都是站在自己角度的,会误导吴总的判断,有建议单片机,有建议仓颉,说真的,真搞出来,他不会去用的.他甚至都没了解单片机或仓颉开发,就要中文开发,想想都可笑.
所以一定要避免误导性投票:用户需求可能片面(如“要单片机支持”但实际不会用).
多发些IDE优化投票,语法优化投票,对于用户来说,语法出一些语法糖,这些更实在一些.
[最后 个人总结]
1.坚持低代码+中文编程:服务教育、中小企业,降低技术门槛。
2.全力推进H5子平台:基于Vue实现跨端,完善生态闭环。
3.彻底改革库生态:让用户能自主封库(AI辅Zhu),解放官方压力。
4.谨慎对待投票:优先解决IDE体验和语法痛点,而非分散资源。
技术应该服务人,而非让人适应技术。
火山的目标,是让中文开发者拥有真正属于自己的高效工具.
|
|