v1.0, by Liigo, 20170912.
原创链接：http://blog.csdn.net/liigo/article/details/77964660
写在前面
火山安卓开发平台”娃娃#2”版于2017年8月3日发布，作者吴涛。我针对此测试版本给作者提了一点意见和建议，并得到吴总亲自答复。征得吴总同意后连同意见和回复一并发布。文中以红色文字突出标示吴总回复文本。
火山软件开发平台(voldev.net)：是一种目的硬件设备无关、目的软件环境无关、易学易用实用、完全本地化的软件快速开发平台，目前已经实现了【火山安卓软件开发平台】和【火山游戏软件开发平台】两个子平台，更多适用于其它设备和环境的子平台软件正在开发中。
火山软件开发平台是火山编程语言、火山开发库、火山IDE的集成。
关于源代码文件存储格式
建议用纯文本的源文件，不建议用二进制私有格式的源文件。
吴总回复：企业版本会提供此功能,就是考虑到企业开发团队协作较多.
二进制格式源文件有以下缺点：
- 一旦损坏不易恢复，哪怕坏一个字节也可能导致整个文件打不开，损失惨重。无论以前的.e还是现在的.v都有文件损坏的先例，给用户较大的心理负担。
- 不能很好的适应GIT/SVN这类版本管理系统，无法通过对比观察前后变动部分，给源码管理、协同开发、代码评审制造阻力。
可以做一些市场调查看看有多少企业用户能够接受以上缺点。
纯文本格式源文件没有这些缺点：
- 即使文件局部损坏，不影响未损坏部分
- 对比历史版本，可以看到修改、删除、增加的每一行代码，方便管理、协同、评审
如果切实需要存储某些二进制数据，可考虑在项目cache目录内生成辅助存储文件。
是否采用纯文本格式存储，和是否采用表格式展示，两者是不矛盾的。因为前者是存储，后者是形式，理应彼此相对隔离。
关于表格式源码展示形式
我基本赞同用表格式源码展示形式，也可以接受传统的文本展示格式。
表格式的优点是形象、直观，无需记忆繁琐的语法。
表格式的缺点是，需要从头开发编辑器，是一个很大的开发负担。可以看一下现在针对程序员的纯文本编辑器，如 VSCode, Atom, Sublime Text, EmEditor，已经十分先进了，各种方便的、人性化的特性，层出不穷。作为对比，易语言IDE中的文本编辑部分，仅仅是具有最基本的编辑功能。
在流程控制语句块的内部，缩进摆放定义局部变量的子表格；缩进层次不同，子表格左边缘位置也不同。这种做法严重挑战用户体验。像在屏幕不同位置贴满膏药，那画面太美。其实只需要简单的一行代码var v = 1;就能基本满足最常见需求；其他需求还是放到顶部变量表中解决。
吴总回复：这个地方估计是没有习惯的地方,不能前面用表格,后面用var定义,两者需要保持一致.需要考虑到火山的目标用户群体仍然不是专业程序员,表格可以减少关键字记忆量,是必不可少的.
关于目标平台API
最好能支持直接调用Android平台API，次选项是自动生成调用接口。
人工封装接口应视为锦上添花行为，做更高层次的优化的接口设计。
前期依赖（官方的和第三方的）大量人工的机械的封装的接口，这条路估计会漫长而曲折。
吴总回复：考虑到火山的用户群体,接口封装是必不可少的,好在现在这方面的免费资源很多,到时候直接拿过来封装就行了.火山同样提供了直接在程序中调用目标语言的语句.
像Kotlin Scala那样既可无缝调用Java API，又能封装上层接口，是较好方案。
封装的API接口应准确而详细的返回错误信息。避免像易语言那样多数时候仅仅返回假，调用者知道调用失败了，却不知道究竟错在哪里，更无法做针对性修正。
关于开发环境
这里说的是开发火山平台所用的开发环境。
推测现在采用的开发环境：VC++ 2013, MFC v12, Java 1.6。可能还用到某些类似COM的技术，如插件接口处。
吴总回复：开始开发前考虑了很久,之所以选用vs,主要还是因为以下原因:
1.目前最主要的工作前端操作系统还是windows;
2.对于windows界面组件的细节我了解得比较多,选用vs能够快速进入开发状态而且避免出现意外;
3.使用的是我自己定义的跨平台com接口技术,这种技术不依赖windows,也就是说,不会出现类似易语言绑定在windows和mfc的情况;
4.插件基本没有用mfc,全部使用的是我自己的跨平台类库;
5.如果需要修改为跨平台版本,只需要修改ide的界面部分即可.
这些都比较旧了。就像当年的VC6 + MFC6一样的旧，易语言用了它之后就一直是VC6 + MFC6，未能与时俱进。
而且不能跨平台。
组织团队开发火山的话，建议选择比较新的、大众化的、跨平台的技术，例如QT 5（做界面是非常专业的），或者也可以考虑基于Electron（配备一个熟悉前端的同事，用HTML/CSS/JS做界面应该是很方便的，做各种效果都方便，例子有Atom/VsCode等）。如此利于招聘新同事。
关于其他
火山语言滥用@符号的现象十分严重，用户体验差
吴总回复：哈哈,我也是尽量避免使用多个不同的符号增加记忆量,再说了这个符号也就是L层用户使用,对于主要的H级用户,基本接触不到.
@成了万金油，不同场景随处用，符号本身没有语义，可读性不好，我都被搞糊涂了。建议仔细设计现有每一处用到@的地方，尽量彻底消除@，实在不行用关键字也好一些。
关于嵌套的Java代码块，我第一感觉是采用如下写法：
` ` `java
System.out.println(“”);
` ` `
因为这是 Markdown 语法中嵌套代码块的标准写法，应用十分广泛，多数程序员都熟悉。而且扩展性良好，天然的支持其他非Java语言代码（java->other）。
另外易友提议的如下写法，我认为也挺好：
@java {
System.out.println("");
}吴总回复：这个功能正在实现中
每行Java代码前面都加@的话，需要依赖IDE自动添加（复制进来）和去除（复制出去）@的功能，且需要用户执行额外的操作（非普通的Ctrl+C/V）。
在嵌套的Java代码内使用火山名称，可采用类似如下语法：
<变量:变量1>
<全名:类1>如果考虑支持泛型的话，<>可能需要换成别的符号（如果不换是否可行）。
如果取消“字面字符串”的话，在属性表里，是否可以减少对@的使用呢。
对于@安卓.窗口.布局这类属性名称，可否与语言类型系统相结合，如视之为包.包.文本常量或包.包.常量类。
项目文件格式
我打开.vsln .vprj后第一感是，哦，用了自己发明的轮子格式，没用市面上通行的国际标准格式。后来看到属性表等处也用了这种格式，多处通用，比INI表达力强，比JSON简洁，也挺好。唯一缺点就是花括号嵌套太多了，如果支持数组应该能好点。
吴总回复：我也想过用json或xml什么的,但是总是感觉有一些地方不能满足我的需求,就使用了我自己的类库里面的一个格式,其实这个格式还有很多功能支持,只不过没展示出来.
其他的其他
属性表里大量的转义字符（
\"\n）导致可读性差，可考虑在单元格里以紧凑模式显示吴总回复：这个估计有些难,毕竟空间有限,目前的解决方案是单击一个按钮弹出一个对话框全部显示.
火山IDE和文档中大量使用斜体汉字，不宜识读，用户体验差，应避免之（我以为全国人民都知道呢）
吴总回复：抽时间整理一下
火山IDE错误输出栏未使用等宽字体，导致错误指示符
^指向错误的地方吴总回复：实际上,基本90%的错误都被我自己的编译器拦截了,剩下未被拦截被javac识别出来的错误,由于涉及到符号文本转换(目标符号名(“rg_xxx”)到源程序符号名),转换后基本对齐也是无望,所以只能是参考.
火山语言应尽量支持闭包和泛型这两个功能，意义重大（但不急迫）
吴总回复：闭包够呛,泛型正在开发中.
Liigo回复：如果能够二选一，我宁愿先选闭包(clousre)。这是可以改变代码书写方法的特性。当然听到即将支持泛型我还是很开心，然而GO同学可能并不开心。按下F7编译哪个项目设定不明确：当前前台打开的文件可能同时隶属于多个项目（例如
android_controls.v）吴总回复：F7编译当前项目
Liigo回复：然而“当前项目”的设定也不明确（我已证实不是“活动项目”）。生成Java代码应符合约定俗成的规范，如package名称全部小写，方法前添加必要的空行，方法内部末尾无需多余的空行
- 生成Java代码时不应消除注释，反而应保留原有注释，并额外生成必要的注释
- 生成的Java名称前加
rg_前缀看着怪怪的（也不符合命名规范），最好是没有这类前缀 把
系统翻译成JiTong也是无语（多音字的问题要怎么解决）吴总回复：生成的java代码目前主要保证能够被javac编译通过,阅读性在以后增强.
添加”rg_”是为了确保不会出现名称冲突,因为用户可以自行定义输出名.多个按钮都触发同一个
按钮_被单击事件方法，这样真的好么，耦合更多吴总回复：为了支持挂接动态生成的组件的事件,基本没得选择…
吴总回复：最后: 其实如果仅仅针对java平台,可以做得更好一些,但是需要考虑到以后的其它目标平台,尤其是c,很多地方不得不做出一些放弃.
吴总回复：感谢你提出的建议!