Open cangshou opened 2 years ago
这个真不至于,因为中英文符号的问题,实际使用中的体验非常差,而且编程实际场景里还有等宽阅读等方面的诉求,中文关键字是个非常错误的想法,这如同大写汉字数学在会计标记中是好用的,但是在微积分运算中搞纯中文大写数字,高等数学将是一场灾难一样,不要事事都苛求绝对汉字化。与其提这种需求,不如帮忙做一下中文文档。
用开放的心态,务实的心态来做事吧。如果连编程关键字的门槛都不愿交付,还是不要碰这个东西了。
这不是为我自己用提出来的建议,而是为了广大非专业编程需求的用户提的建议。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 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.如果有抢业余用户的打算,那么就一定要考虑到他们绝大多数所实际拥有和使用的设备条件。
这个提议好!先用json表明替代的字符,就是难实现一点......而且只要有9年教育就可能看得懂一点英文吧
我是差生嘛。看不懂英语也没办法。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 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按四下,初始化至少按十下吧?改成“csh”?这不又回去了?
初始化,我看懂只需要看一眼,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: @.***>
要学多少新东西?
不想学新东西是不是就有点过分了
不懂英文的外行初学者,要进入你说的“多写写”要走多少思维路途?要新学多少东西?没等到能“多写写”的程度就有多少放弃、阵亡了?另选编程工具了? 除非一开始就有巨大的利益刺激摆在那里。
没的选择,用户会去学点儿新东西,有替代有选择,谁愿意多一道手续?
你的想法是降低门槛,提升新手友好度,这是好事。 但是我认为即使是通过这种方法降低了门槛,但是入门以后不论是为了扩展还是为了效率亦或是为了其他原因,早晚还是要接触其他的“英文”编程语言,包括“英文版”HVML。 该付出的一点都不会少,这是弯路,不可取。
没有利益,用户连多按一下手机屏幕都不愿意,何况更复杂的事情。
没有利益,用户连多按一下手机屏幕都不愿意,何况更复杂的事情。
写代码的人不是用户,是创造者。你概念里的这种人是不会来写代码的,也不值得被争取。
对于非英语的业余用户来说,思维的简单性和降低学新知识的思维成本才是重要的。当然,入门后就另一说了。 至于您说的 ”这种人是不会来写代码的,也不值得被争取“ ,我持保留态度。
我是觉得肯学的人不差这一点,不肯学的人无论如何都不肯学。 您要觉得“就差这一点”,那我们只能求同存异了。 Agree to disagree.
init按四下,初始化至少按十下吧?改成“csh”?这不又回去了?
楼上已有IDE插件提供中文标识符辅助补全功能,对语言本身的支持在技术上应该也没问题。 当然更大的优势的确是可读性,毕竟读代码的时候远多于写的。
编程界面搞成scratch那种就完事了,拖拖拖 比 打字还方便吧?
这样很好的,提供这一特性花费力气不太多,却方便了海量业余用户。
---- 回复的原邮件 ---- | 发件人 | 吴烜 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: @.***>
@KenLSoft 图形化编程工具虽在某些场景下提供便利,但业务复杂度上去之后在各方面受限不小。一些个人体会见此文后半段:https://zhuanlan.zhihu.com/p/85081589
母语编程想法很好,但目前,个人认为,更关键的是,实现 HVML 的所有定义功能,提供准确、全面、完整的开发示例,以及使用HVML开发出具有代表性的典型产品,只有 HVML 语言真的可用、实用、好用了,才是考虑母语编程等其他更进一步的想法、功能的时候。
同意。母语编程只是附加特性,可以晚点做。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2022年11月14日 13:58 | | 收件人 | @.> | | 抄送至 | @.**@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程,帮助业余用户零基础拿来即用! (Issue #17) |
母语编程想法很好,但目前,个人认为,更关键的是,实现 HVML 的所有定义功能,提供准确、全面、完整的开发示例,以及使用HVML开发出具有代表性的典型产品,只有 HVML 语言真的可用、实用、好用了,才是考虑母语编程等其他更进一步的想法、功能的时候。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
只有 HVML 语言真的可用、实用、好用
语法和反馈信息母语化可以提高相当实用、好用、易用方面优势。这与语言工具链功能开发没有很大冲突,因为它更侧重的是前端设计,而开发量相对小很多。
说得对!
---- 回复的原邮件 ---- | 发件人 | Xuan @.> | | 日期 | 2022年11月14日 17:50 | | 收件人 | @.> | | 抄送至 | @.**@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程,帮助业余用户零基础拿来即用! (Issue #17) |
只有 HVML 语言真的可用、实用、好用
语法和反馈信息母语化可以提高相当实用、好用、易用方面优势。这与语言工具链功能开发没有很大冲突,因为它更侧重的是前端设计,而开发量相对小很多。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
这不是为我自己用提出来的建议,而是为了广大非专业编程需求的用户提的建议。
我希望了解你所认知的广大非专业编程需求的用户都有哪些需求,以及市面上是否已有成熟的解决方案,例如:经常操作报表的人需要办公自动化,可以使用SeaTable脚本,等。
这样很好的,提供这一特性花费力气不太多,却方便了海量业余用户。
业余用户可以说确实 “海量” ,但若是没有铺天盖地的宣传,则实际上很难出圈。本质来说,这样一个项目能吸引到的所谓蓝海增量是很有限的,因此,你所说的没有利益连多按一个按钮都懒得
同样适用于产品开发侧。
至于您说的 ”这种人是不会来写代码的,也不值得被争取“ ,我持保留态度。
写代码的人不是用户,而是创造者。
请容许我引用这句话并强调之。
零基础拿来即用的目的就是基本不用学(或直接边用边学)。
没有任何一种脚本/语言,包括HVML,符合你的要求。因为即便是英文母语者,使用任何一门脚本语言都是要投入学习的。而所谓边用边学,这只适用于对计算机科学技术有较高理解的人中,他们可以通过直觉,判断一个新接触的语言的底层行为,从而实现边用边学,甚至直接用而不学习。
初始化,我看懂只需要看一眼,init我看懂需要几眼?脑子要转几个弯?要学多少新东西?
真正的零基础者是不知道 “初始化” 一词的含义的,即便他们从字面意思上理解也无法完全得知这一关键字的具体行为,因为对于编程语言来说,有很多种行为都被称为初始化(init)。而他们学习得知初始化这一词的学习成本,与他们学习init这一词的成本几乎相同,本质就是在搜索引擎打出这个词并阅读查询结果罢了。
上面这种写法读起来真舒服,清晰、易懂、直观。
既然如此舒适清晰直观,能否尝试根据这个案例进行新代码的创作?
我是差生嘛。看不懂英语也没办法。
事实上我不太认可这是一个能理直气壮地直说的理由,不会的话就应该去学。如果不想学,我认为直到世界上有价值的中文文献比英文文献多的时候才有可能实现。
当然,入门后就另一说了。
一昧地强调降低入门的门槛,也只会增加更多的低级入门者。低级开发者数量再多,迈向高级开发者的人数量都是不变的。
简单易学这一特性应该面向谁?对职业程序员谈这四个字有意义吗?只有对还不是程序员的人(业余用户)谈这这四个字才有意义。否则基本只会在存量程序员的圈子里抢用户。当然,如果HVML没有抢(业余用户)的欲望就算了。
业余用户,没钱(原谅我在开源社区里谈钱,这里的目的只是列出他们的特质之一),事多,思考少,进步慢。吸引来一大批没有任何好处,甚至可能会多出一批到处说“XX脚本复杂难学”的人,何苦?
上述内容只是对本ISSUE的部分论据感到忍俊,而对于题目本身,支持母语编程,我算是支持的,尽管我不会去用,但这至少是一个比较有趣的特性,也可能可以在奇奇怪怪的地方开发出有意思的玩法(例如在c语言中,使用#define实现的各种有趣的正文代码),而且对于提出的json这一方案来说,也相当于给关键字添加别名功能,替换目标也可以并非是母语,也可以是其它的英文单词,例如让已存在的两个关键字互换等。
母语编程是为了满足非专业性编程需求,至于能否得到满足,要看魏永明先生愿不愿意或认为划不划算了。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2023年01月09日 14:43 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程,帮助业余用户零基础拿来即用! (Issue #17) |
这不是为我自己用提出来的建议,而是为了广大非专业编程需求的用户提的建议。
我希望了解你所认知的广大非专业编程需求的用户都有哪些需求,以及市面上是否已有成熟的解决方案,例如:经常操作报表的人需要办公自动化,可以使用SeaTable脚本,等。
这样很好的,提供这一特性花费力气不太多,却方便了海量业余用户。
业余用户可以说确实 “海量” ,但若是没有铺天盖地的宣传,则实际上很难出圈。本质来说,这样一个项目能吸引到的所谓蓝海增量是很有限的,因此,你所说的没有利益连多按一个按钮都懒得同样适用于产品开发侧。
至于您说的 ”这种人是不会来写代码的,也不值得被争取“ ,我持保留态度。
写代码的人不是用户,而是创造者。请容许我引用这句话并强调之。
零基础拿来即用的目的就是基本不用学(或直接边用边学)。
没有任何一种脚本/语言,包括HVML,符合你的要求。因为即便是英文母语者,使用任何一门脚本语言都是要投入学习的。而所谓边用边学,这只适用于对计算机科学技术有较高理解的人中,他们可以通过直觉,判断一个新接触的语言的底层行为,从而实现边用边学,甚至直接用而不学习。
初始化,我看懂只需要看一眼,init我看懂需要几眼?脑子要转几个弯?要学多少新东西?
真正的零基础者是不知道 “初始化” 一词的含义的,即便他们从字面意思上理解也无法完全得知这一关键字的具体行为,因为对于编程语言来说,有很多种行为都被称为初始化(init)。而他们学习得知初始化这一词的学习成本,与他们学习init这一词的成本几乎相同,本质就是在搜索引擎打出这个词并阅读查询结果罢了。
上面这种写法读起来真舒服,清晰、易懂、直观。
既然如此舒适清晰直观,能否尝试根据这个案例进行新代码的创作?
我是差生嘛。看不懂英语也没办法。
事实上我不太认可这是一个能理直气壮地直说的理由,不会的话就应该去学。如果不想学,我认为直到世界上有价值的中文文献比英文文献多的时候才有可能实现。
当然,入门后就另一说了。
一昧地强调降低入门的门槛,也只会增加更多的低级入门者。低级开发者数量再多,迈向高级开发者的人数量都是不变的。
简单易学这一特性应该面向谁?对职业程序员谈这四个字有意义吗?只有对还不是程序员的人(业余用户)谈这这四个字才有意义。否则基本只会在存量程序员的圈子里抢用户。当然,如果HVML没有抢(业余用户)的欲望就算了。
业余用户,没钱(原谅我在开源社区里谈钱,这里的目的只是列出他们的特质之一),事多,思考少,进步慢。吸引来一大批没有任何好处,甚至可能会多出一批到处说“XX脚本复杂难学”的人,何苦?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
抚子日语编程语言的初衷是 “任何人都可以轻松编程” 「なでしこで誰でも簡単プログラマ」。 何必将开发者贴上”专业“/“非专业”的静态标签、还将工具特性绑定在两个标签之一?
Nadeshiko 面向“编程初学者”和“想要实现处理自动化的人”。
抚子发布已经16年了,听说曾经是学生的用户已经成长为优秀的程序员。我们收到了许多“因为我是抚子所以能够开始编程”的快乐反馈。以抚子为入口,您可以升级到各种编程语言。一旦掌握了编程技能,就很容易学习另一种编程语言。
事实上,根据去年进行的抚子用户调查发现,大部分用户都在 30 到 40 岁之间,其中也有不少人将其用于商务。
其实如果报错提示支持中文就已经很不错了。但是优先级比不上编辑器自动补全,语法高亮插件这些。要先想办法让写html的程序员能转过来,然后再顾及英文小白。
诚然,英语确实是程序员的基本技能,但一个中国人开发的项目,没有中文成分也是万万不可的。
母语编程可以作为一个插件或子集,母语编程受众太少,并且就算把英文关键字换成中文也不能让新手拿来即用,既然都是要查文档学习用法,为何还要把关键字全部换成英文?
一个需求而已。有没有用得看需求方。提供不提供,要看魏永明先生觉得划算不。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2023年01月26日 09:36 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | 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: @.***>
我认为编程语言中的关键字,就跟阿拉伯数字,数学符号,化学元素符号一样。比如 for,while,if,else,return 我一直都不知道在英文中是什么意思,我只知道在编程语言中是什么意思。要降低编程难度,应该实现各种文档中文化。
英语编程用户入门容易,因为他们有类似“代码即文档”的语言优势,我们也需要这样的体验。
---- 回复的原邮件 ---- | 发件人 | @.> | | 日期 | 2023年05月14日 15:37 | | 收件人 | @.> | | 抄送至 | @.>@.> | | 主题 | Re: [HVML/PurC] 建议将HVML搞成母语编程,帮助业余用户零基础拿来即用! (Issue #17) |
我认为编程语言中的关键字,就跟阿拉伯数字,数学符号,化学元素符号一样。比如 for,while,if,else,return 我一直都不知道在英文中是什么意思,我只知道在编程语言中是什么意思。要降低编程难度,应该实现各种文档中文化。
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
文档写好就行,但是反对使用中文进行编程,编辑器支持太差,效率太低。
我觉得这个可以考虑,但不优先,留给以后一个个加,做彩蛋也是可以的。作为自己的母语,大家都希望能实现,不论难易优劣,但基于综合因素,优先考虑或作为一个特点,都操之过急,眼下做好操作系统才是大环境的需求,这个可以留到以后再慢慢研究,说不定那时已经有了更完善的理论支持,也鼓励相关爱好的朋友积极研究,完善理论,国内已经有一个凹(wa)语言在这方面积极探索,大家也可以了解一下呢
@kobayashilin1 楼上的 Intellij系 中文标识符补全插件 已破百万下载。
效率请参考:甲方爸爸们请看过来:代码用中文命名,真香!
建议搞个json,如{“language”:[“en”,“zh”,……],“keywords”:[[“init”,“初始化”,……],[“as”,“作”,……],[“on”,“在”,……]……},编辑器用此json将HVML搞成母语编程,机器用英语版,用户用母语版,就有可能帮助业余用户零基础拿来即用!