PurC
PurC copied to clipboard
HVML
建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！
建议搞个json，如｛“language”:［“en”,“zh”,……］,“keywords”:［［“init”,“初始化”,……］,［“as”,“作”,……］,［“on”,“在”,……］……｝，编辑器用此json将HVML搞成母语编程，机器用英语版，用户用母语版，就有可能帮助业余用户零基础拿来即用！
这个真不至于，因为中英文符号的问题，实际使用中的体验非常差，而且编程实际场景里还有等宽阅读等方面的诉求，中文关键字是个非常错误的想法，这如同大写汉字数学在会计标记中是好用的，但是在微积分运算中搞纯中文大写数字，高等数学将是一场灾难一样，不要事事都苛求绝对汉字化。与其提这种需求，不如帮忙做一下中文文档。
这不是为我自己用提出来的建议，而是为了广大非专业编程需求的用户提的建议。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2022年08月11日 12:56 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
用开放的心态，务实的心态来做事吧。如果连编程关键字的门槛都不愿交付，还是不要碰这个东西了。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
不是要搞成仅使用中文编程，而是让专业用户和机器用英文版，业余用户按需使用(或翻译成)自己的母语版。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2022年08月11日 12:55 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
这个真不至于，因为中英文符号的问题，实际使用中的体验非常差，而且编程实际场景里还有等宽阅读等方面的诉求，中文关键字是个非常错误的想法，这如同大写汉字数学在会计标记中是好用的，但是在微积分运算中搞纯中文大写数学将是一场灾难一样，不要事事都苛求绝对汉字化。与其提这种需求，不如帮忙做一下中文文档。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
与专业编程相比，业余编程用户和需求才是汪洋大海！
漠视这一点的人多半陶醉在专业化编程高人一等的优越感中不肯低下身来。
还有很多人是还没有意识到这个问题，所以没来得及行动。
我虽然不会编程，但相信母语化编程+对业余编程友好，会是未来很流行的特性之一。
您提到的飞鱼(解释器/编译器)好像是闭源的，思路好像有借鉴火山平台，对吗？ 如果是这样，就走了闭源母语编程的老路了，前面已有易语言和火山平台探索过，路不好走。我觉得这样搞将来干不过开源的(如双许可证的)。
---- 回复的原邮件 ---- | 发件人 | 吴烜 xuan @.> | | 日期 | 2022年08月14日 13:50 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
飞鱼 有 这样设计：
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: @.***>
1.我不是程序员，也不会编程，但不是没有学习一点点编程语言。 2.零基础拿来即用的目的就是基本不用学(或直接边用边学)。
---- 回复的原邮件 ---- 发件人Link @.>日期2022年08月15日 @.@.@.>主题Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) 所以为什么不先学一下编程语言再回来思考这个问题呢？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
如果说对专业编程人员和专业编程需求，我确实不够了解；但对于业余编程人员和业余编程需求，我自己就是这样的人，也见过了非常多的这样的人，也潜水过很多这样的人的圈子，应该说了解的差不多算“够”吧。
---- 回复的原邮件 ---- | 发件人 | Link @.> | | 日期 | 2022年08月15日 22:59 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
如果对某种事情不够了解，过早提出的见解或建议往往是有问题的。还是建议至少熟悉一门编程语言后再回来看这个问题
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
HVML不强调简单易学也就罢了，如果强调，那么我认为: 1.简单易学不是一个编程语言留人的特性，而是抢(新)人的特性。 2.简单易学这一特性应该面向谁？对职业程序员谈这四个字有意义吗？只有对还不是程序员的人(业余用户)谈这这四个字才有意义。否则基本只会在存量程序员的圈子里抢用户。当然，如果HVML没有抢(业余用户)的欲望就算了。 2.简单易学不是一个静态的特性，没有最简单，没有已经够简单，只有更简单，就像从汇编到c到C++到python再到HVML……会不断的进化下去。 3.如果有抢业余用户的打算，那么就一定要考虑到他们绝大多数所实际拥有和使用的设备条件。
我是差生嘛。看不懂英语也没办法。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2022年08月18日 20:51 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
这个提议好！先用json表明替代的字符，就是难实现一点......而且只要有9年教育就可能看得懂一点英文吧
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
抛开母语化编程的意义不谈，我们单谈如何定义。
我很早以前就琢磨过中文化关键词。从直观上讲，使用标记之后，的确可以将大部分关键词替换成母语。但同时也遇到了一些问题。比如用中文为例：
<init as 'TIMERS' uniquely by 'id'>
<iterate on "$users" to "append" in "#the-user-list" with "$user_item" by "CLASS: IUser">
<update on "$DOC.query('#the-user-list > li')" at "attr.class" with $text_info />
用中文可以如下书写：
<初始化 为 '定时器' 以 '标识符' 限唯一>
<迭代 于 "$用户们" 做 "追加" 在 "#the-user-list" 用 "$user_item" 以 "CLASS: IUser">
<更新 于 ‘#the-user-list > li' 於 ‘attr.class’ 用 $文本信息 />
可以看到，中文很难区分 at 和 on 这两个介词。使用其他语言，相信也会有类似问题存在。
和母语化关键词可能带来的巨大争议不同，我们计划首先支持 Unihan 字符（CJK 中文字符）作为变量名。
@VincentWei 谢谢分享！支持从中文标识符开始。
仅探讨设计的话，上面的例子，为避免介词混淆，也许可考虑用更接近中文语法的设计，比如：
<将 ‘#the-user-list > li' 的 ‘attr.class’ 值更新为 $文本信息 />
也可以与报错信息的句式一道考虑，使术语和风格接近。假如说，上面的语句误用了不存在的属性名“距离”的话：
<将 ‘#the-user-list > li' 的 ‘距离.class’ 值更新为 $文本信息 />
不知当前会如何报错呢？
是的，变量和函数名称支持多语种要容易些，语法关键字(保留字)翻译因为要考虑各母语用词和语法习惯，所以更难，而HVML在这方面好像比其他编程语言还要难一些。 当初易语言好像几乎是直接翻译的Basic语法，火山平台好像在翻译JAVA(安卓平台)和C++(视窗平台)时进一步做了封装抽象和语义化，遇到的翻译都没有HVML这么难，基本都能做到一一对应和望文知意，业余用户新接触的时候上手很快，几乎是做到了零门槛(他们能生存到现在是有一定道理的)。 HVML的英文版在阅读起来几乎是接近于生活语言了，我甚至都在想它将来是不是可以用语音输入编程了？ 但是，也因为HVML接近于生活语言的特点，使得他比其他编程语言进行其他语种翻译难度增大了许多！ 这是个很令人头疼的问题，可以放到英语版完成后去解决。如果能解决这个问题，我相信将来的代码语言真的能距离生活语言越来越近，越来越易于被大众所使用了。 但这种给开发团队增加额外负担的事情，必须要有利益推动才行。我所见到的现实例子就是开源团队围绕自己的产品(如编程语言或相关的支持库)自己搭建教学、供需对接、交易担保和抽成一体化的综合性网站，快速培养庞大的免费用户群，并在服务免费用户群的过程中获取教学、保交易抽成、定制服务等方面的收入。 (搭建精易论坛的公司用这种模式养活了一个易语言开源模块的维护团队，顺带养活了公司其他产品。但这个论坛却不是易语言官方自己搭建的，没用来养活易语言官方自己的开发团队，真是一个讽刺。)
---- 回复的原邮件 ---- | 发件人 | 吴烜 xuan @.> | | 日期 | 2022年08月19日 11:51 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
@VincentWei 谢谢分享！支持从中文标识符开始。
仅探讨设计的话，上面的例子，为避免介词混淆，也许可考虑用更接近中文语法的设计，比如：
<将 ‘#the-user-list > li' 的 ‘attr.class’ 值更新为 $文本信息 />
也可以与报错信息的句式一道考虑，使术语和风格接近。假如说，上面的语句误用了不存在的属性名“距离”的话：
<将 ‘#the-user-list > li' 的 ‘距离.class’ 值更新为 $文本信息 />
不知当前会如何报错呢？
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
@nobodxbodon 提到的更接近中文语法的设计，存在难以处理关闭标签（形如</iterate>）的问题：
<将 ‘#the-user-list > li' 的 ‘attr.class’ 值更新为 $文本信息 />
合理的设计还是应该使用动词作为标签名称：
<更新 ‘#the-user-list > li' 的 ‘attr.class’ 为 $文本信息 >
...
</更新>
再比如针对比较复杂的元素，可使用逗号，看起来更舒服：
<初始化 为 '用户们'，来自 'https://foo.bar.com/users.json'，用 'id' 做唯一键 >
<迭代 $用户们，经 'CLASS: IUser' 处理，在 '#the-user-list' 中做 '追加'，用 $用户项 为模板>
...
</迭代>
</初始化>
这样设计的话，针对不同的语言，需要重写对应的解析器，不是简单替换关键词就能做到的。
`<初始化 为 '用户们'，来自 'https://foo.bar.com/users.json'，用 'id' 做唯一键 >
<迭代 $用户们，经 'CLASS: IUser' 处理，在 '#the-user-list' 中做 '追加'，用 $用户项 为模板>
...
</迭代>
</初始化>` 上面这种写法读起来真舒服，清晰、易懂、直观。
针对不同的语言，需要重写对应的解析器，不是简单替换关键词就能做到的。
的确，还有额外的相关辅助功能如IDE的中文补全提示（Intellij系有 此插件辅助标识符补全）。在编程母语化的趋势下（如 “抚子”日语编程语言已进入中学教学），个人看来不失为前瞻性的~~技术~~设计探索。
另外，关于编译器会反馈哪些报错信息，不知有文档介绍吗？
初始化，我看懂只需要看一眼，init我看懂需要几眼？脑子要转几个弯？
降低门槛不是要去比能少按几个键，而是去比能减掉多少认知步骤。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2022年08月24日 23:36 | | 收件人 | @.> | | 抄送至 | @.@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) |
init按四下，初始化至少按十下吧？改成“csh”？这不又回去了？
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
初始化，我看懂只需要看一眼，init我看懂需要几眼？脑子要转几个弯？要学多少新东西？
降低门槛不是要去比能少按几个键，而是去比能减掉多少认知步骤。
---- 回复的原邮件 ---- @.>日期2022年08月24日 @.@.@.>主题Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) init按四下，初始化至少按十下吧？改成“csh”？这不又回去了？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
- 还是不熟悉，多写写就不用转弯了。
- 写代码不单是脑力劳动也是体力劳动，字数就是工作量。
cangshou @.***> 于2022年8月25日周四 00:09写道：
初始化，我看懂只需要看一眼，init我看懂需要几眼？脑子要转几个弯？要学多少新东西？
降低门槛不是要去比能少按几个键，而是去比能减掉多少认知步骤。
---- 回复的原邮件 ---- @.>日期2022年08月24日 @.@.@.>主题Re: [HVML/PurC] 建议将HVML搞成母语编程，帮助业余用户零基础拿来即用！ (Issue #17) init按四下，初始化至少按十下吧？改成“csh”？这不又回去了？ — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
— Reply to this email directly, view it on GitHub https://github.com/HVML/PurC/issues/17#issuecomment-1225934354, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAXPYJNRDY6IEOK7IKCPHYLV2ZCKDANCNFSM552JBSBA . You are receiving this because you commented.Message ID: @.***>
-- http://about.me/mountainwang
不懂英文的外行初学者，要进入你说的“多写写”要走多少思维路途？要新学多少东西？没等到能“多写写”的程度就有多少放弃、阵亡了？另选编程工具了？ 除非一开始就有巨大的利益刺激摆在那里。
你的想法是降低门槛，提升新手友好度，这是好事。 但是我认为即使是通过这种方法降低了门槛，但是入门以后不论是为了扩展还是为了效率亦或是为了其他原因，早晚还是要接触其他的“英文”编程语言，包括“英文版”HVML。 该付出的一点都不会少，这是弯路，不可取。
没有利益，用户连多按一下手机屏幕都不愿意，何况更复杂的事情。
写代码的人不是用户，是创造者。你概念里的这种人是不会来写代码的，也不值得被争取。
对于非英语的业余用户来说，思维的简单性和降低学新知识的思维成本才是重要的。当然，入门后就另一说了。 至于您说的 ”这种人是不会来写代码的，也不值得被争取“ ，我持保留态度。