我的编程之旅

yu258456

前言：     
      时光回溯至2011年，一次偶然的契机，让我邂逅了易语言。彼时，我未曾料到，这一眼，便开启了长达十余年的编程之旅。犹记得，最初萌生学习易语言的念头，不过是想开发一款供自己架设的SF游戏登录器，尽管至今这个愿望仍未实现，但学习的热情一旦点燃，便如燎原之火，一发不可收拾。自接触易语言起，我仿佛踏入了一个全新的世界，对游戏的兴致竟渐渐消散，转而一头扎进编程知识的海洋。无数个夜晚，我通宵达旦地观看世宝老师的入门课程，在代码的世界里如痴如醉，自此正式叩开了编程世界的大门。

      毕_业后踏入职场，凭借着在易语言学习过程中积累的知识，我成功开发出几个实用的小工具。这些成果不仅在工作中发挥了重要作用，还赢得了同事们的一致称赞。对于从小性格自卑的我而言，这些称赞无疑是一剂强心针，极大地增强了我的自信心。易语言，就这样陪伴我走过了从初出茅庐到职场新人的重要阶段，直至2016年。

     2016年，我毅然决定放弃继续深入学习易语言，转而投身Java和C#的学习。当时，我观看了黑马的一些入门课程，凭借着在易语言学习中锻炼出的自学能力，很快便掌握了这两门语言。此后，我又陆续学习了Python、PHP、JS、Vue等各类编程语言，参与了不少项目，在编程的道路上不断探索前行。然而，尽管岁月流转，我对易语言始终怀有一份难以割舍的眷恋。即便日常工作繁忙，我也会偶尔以游客的身份逛逛火山论坛，关注着它的发展动态。不知不觉间，火山已经发布7年多了，但与易语言发布7年后的传播力度和影响力相比，两者之间仍存在着天壤之别。在此，我想分享几点个人浅见，若有不足之处，还望各位大佬海涵。

就火山编程语言自身的发展而言，若想实现持续进步，以下几个痛点亟待解决：

优化文本格式源码

   在编程领域，采用二进制存储源码的方式极为罕见，除了易语言和火山，似乎找不到其他案例。这种格式的弊端显而易见，它极大地阻碍了团队协作，不利于对历史源码进行回溯，更无法借助Git、SVN等版本管理工具进行高效的版本管理。以我个人为例，即便如今独自开发项目，也会使用Git进行代码管理。当源代码出现BUG时，Git能够迅速帮我比对出问题所在，极大地提高了开发效率。因此，优化文本格式源码对于火山的未来发展至关重要。

去掉表格式、支持英文关键字

     一款编程语言若想在激烈的市场竞争中生存并发展壮大，就必须不断吸引新鲜血液的加入。火山历经多年发展，新用户数量究竟如何，我无从知晓。但可以肯定的是，若想吸引主流编程用户，采用英文关键字和非表格式代码是必经之路。这不仅能降低用户的学习成本，还能让他们更快地适应火山的编程环境。我记得当初吴总发布娃娃版#1时，曾邀请Liigo大神进行测试，大神就提出了这个问题，但遗憾的是，吴总当时并未采纳。倘若当时能够采用易语言·飞扬格式代码作为默认格式，并支持替换英文关键字，或许真的能够吸引到主流编程用户的关注。当然，考虑到现阶段.v格式的优化难度，也可以新增一种格式（如.vt），作为不存储表格体、不加密的文本格式代码，以满足不同用户的需求。同时，文本格式代码也更容易被AI所训练，提升开发效率。

增加包管理器

     包管理器堪称OOP编程语言的标配，例如C#的Nuget、Python的pip、Java的maven等。有了包管理器，大神们可以开发第三方库并上传，为火山生态注入新的活力。火山可以在此基础上进行优化，比如推出收费版，官方平台从中收取一定佣金，实现双方共赢。如此一来，官方无需再为适配第三方SDK而疲于奔命，可以将更多精力投入到更有意义的事情上，而不是陷入繁琐的封库工作中。

支持版本管理工具Git、SVN等

     支持版本管理工具同样是编程语言不可或缺的一项功能，它与文本格式的代码相辅相成。只有实现了对版本管理工具的支持，火山才能更好地满足团队协作和项目管理的需求，提升开发效率和质量。

增加新媒体宣传

     在当今的抖音、快手等新媒体平台上，充斥着大量吹嘘华为仓颉编程语言的内容，然而令人啼笑皆非的是，很多截图竟然来自易语言，导致许多小白误以为那是华为的功能。与其让这些不实信息肆意传播，不如火山官方直接开设账号进行宣传，展示自身的特色和优势，吸引更多用户的关注。

结语：

     最后，我想说的是，使用英文关键字并不会增加新人的学习成本。这些年，我一直跟随大学教授创办的公_司中工作，接触过许多大学生。他们或许在逻辑思维和数学能力方面有所欠缺，但英语水平普遍不错。因此，英文关键字并不会成为他们学习火山的障碍。华为的仓颉编程语言不也采用了英文编程吗？从易语言最初的关机小程序，到各类系统的开发，再到独立完成数百万级的半导体设备程序开发，在编程这条路上走了无数个日夜。正是在学习易语言的过程中培养出的超强自学能力，让我能够在编程的道路上不断前行，一路披荆斩棘。衷心祝愿吴总的火山能够越来越好，为中国的信息化产业再创新辉煌！谢谢大家！

numbersir

<火山程序 类型 = "通常" 版本 = 1 />

方法 按钮_被单击 <接收事件 类型 = 整数 注释 = "当按钮被单击后发送此事件">
参数 来源对象 <类型 = 按钮 注释 = "提供事件产生的具体来源对象">
参数 标记值 <类型 = 整数 注释 = "用户调用\"挂接事件\"命令时所提供的\"标记值\"参数值,非此方式挂接事件则本参数值固定为0.">
{
    如果 (来源对象 == 按钮10)
    {
        选择夹1.删除所有子夹 ()
    }
    否则 (来源对象 == 按钮2)
    {
        选择夹1.删除子夹 (1)
    }
    否则 (来源对象 == 按钮1)
    {
        选择夹1.插入子夹 (1, "新的子夹", 0, 组件布局器1)
    }
    否则 (来源对象 == 按钮12)
    {
        按钮7.可视 = 取反 (按钮7.可视)
        按钮11.可视 = 取反 (按钮11.可视)
        按钮13.可视 = 取反 (按钮13.可视)
    }
    否则
    {
        信息框 (来源对象.标题)
    }
    返回 (1)
}

--------------------------------------------
表格代码转文本代码这样多了好多规则，AI一样子也难学会，AI给的文本代码也经常火山IDE不识别

yunwls

飞扬工作室 发表于 2025-6-23 14:24
不会删除的

不删除表格  前端代码很不好编写啊  层级太多了

Morning

表格，易语言的特色吧。我坚持喜欢就是他的清晰

lxhabc123l

感觉向原生靠拢是趋势，像loong编程，直接别名引用各种库，少造好多轮子，VCN直接@{}引用原生代码，跟得上AI时代一小步了，H5最近也要出来了，也是图形化操作，感觉可以吸收他们的优点，结合 自身做一个规划就好了

承易

你的角度不同，你忽略了中国很多一部分人看到英文就头疼的很

lizcst

你说的这些其实吴涛肯定不会弄的，咱先不说吴涛弄得了弄不了，毕竟一人gongsi一人团队，能力也是有上限的。咱就说都加上改好了那火山和VS相比岂不是丢弃了自己的特色东西？就比如这个表格样式代码，这可是祖传的，还有这个加密代码文件，非文本的代码文件也是祖传的，这都是为了强行维持特色或者说是特立独行的风格，如果都向VS看齐，那为啥要去用火山呢？直接用VS不是更好吗？强大到无与伦比，还是免费的，还可以跳过中文转英文的文本替换，省事省力，就是语法是英文的而已，关键是需要的英文词汇量少得可怜，不存在障碍，而且现在VS加入了AI辅Zhu功能，你写中文注释AI都能给你写好英文的C++代码，现在用起来难度更低了，比火山都不知道高到哪里去了。所以，这些吴涛肯定不会丢掉的，记住！这是特色而非缺陷！

zhh044

将代码框变成注释框

绯陌如夏

   深有感触, 感同身受,看得出来字字珠玑

不宜进行短期大幅改变,先明确目标
       不能完全不改变也不能改变过急, 现如今正全力以赴增加H5子平台, 精力不宜过度分散,越是着急越要乱中求稳, H5是至关重要的一关, 在前端发展迅猛的今天, 所有的用户都耗不起了, 传统卡顿+闪烁的MFC 框架 早就让大部分用户为之厌烦了, 性能这一关就是死都迈不过去的坎,


格式代码
这个问题很好解决,火山代码其实完全可以有两种代码风格,官方在增加新款代码渲染组件即可. 无论是用户还是传统代码都可以无缝兼容,也无需废掉表格式,让用户自选择也不失为一种高明策略,让AI生成的同时我们也可以一键预览表格式代码, 事实上这是很多低代码平台最常见的操作了


包管理器版本管理工具Git、SVN等
包括第收费管理软件,肯定是刚需,这也是当今的潮流,可以说,便捷的开发工具能够提升数倍的开发效率

huahaoyueyuan

宣传有钱吗