program-in-chinese / overview

中文编程的历史、现状和展望。issue 中进行相关问题的讨论.

Home Page:https://zhuanlan.zhihu.com/codeInChinese

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

专用帖: 对中文编程的质疑, 困惑, 批评, 吐槽请到此处

nobodxbodon opened this issue · comments

源自: program-in-chinese/Java#1 (comment)

道理不辨不明. 即使是反面的意见也会有正面意义. 欢迎灌水. 将从中提取有用建议到新issue.
此后, 其他帖中的类似内容将被归整到此处(如果是新开的issue将被close, 如果是与原主题帖无关的跟帖回复将被删除).

@ice1000 关于program-in-chinese/Java#1 (comment) 提到的, 个人理解如下:

  • 首先, 我们解决的是一个工程问题. 是否属于计算机科学的范畴就让历史评判好了
  • 说是工程问题的前提是, 需求是客观存在的. 如果我们自说自话不算数, 而且现有的中文编程语言(易,按键精灵等等)的用户也都不算数, 即便国外的英语母语开发者都有设身处地的一些体会. 比如这里最后的引言, 以及这里

虽然暂时这里还算清静, 但迟早宁静会被打破. 其实有点意外, 在知乎上我感觉已经立了挺大一个flag但到现在还没有直接拍我的. 在可能出现的潮水中, 还望各位尽量遵循守则. 当然对于前来无理捣乱的也将直接处理.

主要是有很多很垃圾的人也在倡导这些,比如C#前几天那个闹得特别大的大新闻

@ice1000 我参与了那个讨论啊. 这里就是我的小结. 还是有收获的. 尤其是最后HaloFour对这个刚需的赞同.
中文编程由来争议很多, 个人倒不是很在意. 在辩论过程中发现的一些质疑可能会有价值, 因为短板和缺陷尽早发现也好. 比如中文命名的风格, 也是经常被针对的一个点. 所以开了#45

再补几句. 中文编程的路注定不会平坦. 对它有兴趣的开发者现在肯定是少数, 愿意以开源的形式进行尝试实践的开发者就更少. 这里希望能够集合各种对中文编程的不同方面的思路和实践. 这里列出的至今总结的所有四个方面都各有意义, 相辅相成.

门户之争, 以及各种形式的鄙视链会把原本就寥寥的力量更加分裂. 个人希望尽量避免. 而对于本组之外的有类似目标的声音, 即使不能接纳到组里, 一旦决定参与讨论, 尽量是从他们所述的有理的部分加以尽量客观和就事论事的论述, 其他自己不认同的部分只要不触及底线就不予碰触, 也正是我在那个汉化C#讨论里试图做的. 但这个钢丝比较难走, 最好要保持不偏不倚, 从事实和实践出发, 尽量作为一个独立第三方作纯粹的技术探讨, 而绝不是"选边站".

一句话, 在理性和严谨的前提下, 团结一切可以团结的力量. 这是我个人努力做的.

首先我觉得应该和那个p开头的中文版C#的那个人划清界限

哦不是q开头

我还是觉得, 尽量对事不对人吧. 之前把他请出讨论组(而且block所有access)的决定, 我现在还在检讨. 也许, 当时如果他能在这个讨论组内部发表那个提议, 至少我们还能先作一些工作/劝说. 没有了这个渠道, 也许也是促使他直接向C#组提issue的诱因之一.

退一步说, 尤其是看到 @swizl 的那个知乎回复后, 我觉得至少他的出发点是纯粹的, 相信也代表了不小的一部分人的心声. 尤其是对编程本身不大了解, 但对新技术名词(AI, 智能, 自然语言等等)充满憧憬的(08年我出来的时候也对AI有挺大的憧憬, 在那之前也算写了几年代码, 所以对这种憧憬有些共鸣). 因此在开始对他的一些提议还是尽量从技术角度讨论和建议的. 说到底, 请他出讨论组是因为资源太有限, 假如有人手把手带他入门, 相信他也不会一直徘徊.

那么问题来了. 中文编程的很大一部分受众相信会是对编程无甚了解, 但对技术有憧憬的. 虽然现在也许需要屏蔽一些这些声音来集中精力做实事, 但迟早在推广时几乎是必然会和他们打交道. 那么也许, 在整个实践和语言设计过程中, 也不能完全脱离这个群众基础, 不然恐怕会有无根之水之虞.

我收回之前的两条comments。毕竟code is data,token确实该国际化。重点是国际化而非本土化。

@dou4cc token国际化是指创造新的编程语言时, 支持多种自然语言的token吗? 个人觉得很难设计一种语法适用于不同自然语言. 由于各种自然语言本身语法用法习惯的差异, 简单的token映射的结果应该和汉化现有英文编程语言达到的效果差不多. 更理想的也许是像AppleScript, 对不同语言(法/日语)设计不同的语法. 但在那之前, 不首先推广一个或多个仅支持中文语法的编程语言, 个人感觉是还没会走就想跑.

另外, 中文编程包括的不止语言设计, 还有命名空间. 之前的讨论在#42 (comment). 另在中文编程专栏目录, 初衷和希冀中有详述. 其他issue有命名风格等的深入讨论.

@nobodxbodon 程序语言的语法和自然语言无关。不是支持多种语言的token,而是各种token的名字不存储在源码里,源码里放token id之类的东西,ide显示源码时按语言包显示。

看到这样的水文忍不住冒个泡. 这样带节奏(包括下面的神回复)的恐怕在其他社区还有不少. 不知各位近来有没有看到类似帖子?

@nobodxbodon 主貼裡面舉的第一張圖,還有那個只有一行的中文代碼(那行代碼把 Java 原始結構中的半角括號、半角花括號與半角分號,全都拿掉了,刻意體現出一種異化的感覺),可能有點誇張——或者說戲劇化——了。之所以看上去有些怪,可能是因為表意字符(例如中文裡面的字)與編程裡面用到的一些符號(例如半角括號、半角等號)放在一起,給人一種視覺上的張力(或者說叫人有些緊張),當然這個問題可以通過字體與排版等手段來緩解,我認爲不太適合當作反對中文編程(或者反對用某種非英文的語言來編程)的理由。

另外就是,如果把中文換成其他語言,例如日文、韓文、德文、法文,乃至拉丁文、梵文(如果我可以這樣胡亂舉例的話),那會不會出現這些問題呢?(當然這一段話,尤其是用最後那兩個語言來舉例,完全是我空想的,或許沒辦法和現實對應起來)

刚找到了第一张图的出处: 四年前的如果计算机是由**人发明的,那么编程时写代码会是全中文吗? - 田雅夫的回答 - 知乎 相信原作者的玩笑成分为多.
还找到了这篇文章的前一版本: 如果编程替换成中文就会怎样? 程序员看了表示头疼
发现一些区别, 推敲了一下. 前文的VB例子明显不如中文代码来的一目了然. 因此后文强行改为了Java代码(也不顾易语言和VB的事实关系了), 靠着编辑器的高亮功能勉强得出英文代码更清晰的结论.

而前文中的第一个易飞扬代码(来源), 明显有较强的可读性, 以至于都不敢拿同样功能的英文代码进行比较. 因此后文直接删除了, 以更复杂也更难以一目了然的易语言程序代替. 加了一句在以前初中,老师在上完课后教了我们有趣的易语言中文编程,那时候感觉很有趣, 以示自己有易语言使用经验.

全文的中心似乎是"中文并不适合现有的编程方式", 后面的"未来的发展可能超出你的想象"也是画饼而已. 最大的意外是, 后面竟然提到现代的语言比如Java,都支持Unicode,也就是说可以用中文甚至世界其他语言做变量名和函数名. 本以为如果是全部否定中文编程的文章, 似乎应该回避这个很多初学者都不知道的点. 不过文中的调子还是中文命名不如英文命名, 看来是黑的更高级了一点.

后文的问题又提到:

2.在目前的c++、java等编程语言有使用过中文作为变量名吗?

再看看下面的多数评论对中文命名还是基本反面态度, 说的基本是汉字输入慢, 会有莫名问题, 没规范等等老生常谈.

在腾讯看到另一篇转载, 评论区看到熟人哈, 也看到其他不少对中文编程支持的声音, 不过没什么对中文命名的探讨.

另外, 更早的一个版本中, 用的是"言语", 还有一些错别字. 在后续版本里都修正了, 也是颇为用心了.

前文中有的部分:

screen shot 2018-07-17 at 11 49 27 am

后文中被改成了Java, 和更复杂的易语言代码:

screen shot 2018-07-17 at 11 49 36 am

前文中有的代码示例, 后文中被删去了.:

screen shot 2018-07-17 at 11 50 34 am

@jeffreybaoshenlee 现在看来, 它不仅是黑中文编程语言. 蛮意外的是中文命名被提到台面上了, 而之前看到的绝大多数关于中文编程的网文都只关注易语言为主的中文编程语言. 无论这一波讨论的推手动机如何, 至少中文命名已经成为了中文编程中不得不提的一个方面吧.

@nobodxbodon 其實中文命名,在某種程度上,可以說有着令我意想不到的優勢。

因為英文標識符(包括變量名、常量名、宏名、函數名)如果是由多個單詞(word)所構成的詞組或短語(phrase),那麼就涉及怎樣分隔這些單詞的問題(例如是用下劃線,還是用連字符,或者把每個單詞的首字母大寫,形成所謂駝峰式效果)。

中文裡面,似乎可以暫時不考慮這個問題(真的不用考慮嗎?我不確定,我再想想)。例如剛纔最後一張圖的複製窗口組件,就不用寫成複製-窗口-組件

另外,如果不談拼寫,只談命名,那麼有些程序——尤其是開發者基本上全都是採用某一種自然語言(例如中文)的那些程序——似乎更可以考慮用當地的語言來寫。

亂碼怎麼辦,昨天部門會議報告了中文檔名的解決方案,今天上午處理客戶問題又看到彈窗亂碼.

又发现一个带节奏的知乎问题, 忍不住又回复了: https://www.zhihu.com/question/280213529/answer/445585014

@jeffreybaoshenlee 同感! 当然会有个歧义的问题, 但应该是比较容易规避的. 其实我觉得很神奇的是, 中文命名纵然有着各种优势, 竟然在大多数编程语言都支持Unicode十多年之后还没有在国内大规模使用.

@shyangs 欢迎. 中文编码问题存在了几十年, 中文编程不是为它而生的, 但肯定能促进编码问题的发现和解决. 像你提到的问题, 恐怕要从系统默认编码和编程语言工具编码方式入手诊断, 有个也许类似问题详见 #26https://zhuanlan.zhihu.com/p/30008480)

@bldght 感觉#41 (comment) 更属于这里. 有兴趣的话不妨在这里继续, 在那里恐怕会歪楼.

强烈反对主动推广和商业化,这样搞只会让中文编程变味。

什么属于"主动推广"? 我们这个讨论组和知乎专栏算吗? 那怎样是"被动推广"?

当前**许多人唯利是图,为了赚钱什么事都干的出来, 如果掺杂了利益,难免会有人利用道德绑架,去欺骗外行人。

个人还没发现任何一家敢打着中文编程旗号的公司做着挂羊头卖狗肉的事情. 现在群众素质都高, 只要胆敢冒头的, 一旦被发现猫腻, 肯定早就被唾弃了. 如果你有发现, 烦请告知. 反过来, 像上面发现的水文(详见最近一波对中文编程(包括中文命名)的攻势)可是(十)数年如一日地对外行人和新手进行欺骗性宣传.

一旦这样,中文编程必然会担上恶名,这样支持中文编程的人就会变少。

恶名已经够多了, 再没有团结起来的力量进行尽量的正名和推广, 激浊扬清, 中文编程的大势还会被推迟.

我认为,中文编程应该事实求是的去做,

做和说没有矛盾. 酒香不怕巷子深是理想而不是现实.

能干哪些事,不能干那些事,那些事干起来容易,哪些事干起来困难,向外人清清楚楚、明明白白的说清楚, 不要故意夸大和道德绑架

这也是我们一直尽量在做的. 如果你看到这里或者知乎专栏文章中有夸大不实/道德绑架的成分, 请不吝指出. 但是, 像上面的水文, 摆明了操弄各种误导手段对中文编程进行丑化. 那么, 在我们的对外推广宣传中, 只是侧重自己的客观长处而已, 何况短处也都提了, 已经相当君子了吧? 退N步说, 请问你看到过哪家广告会提到哪怕一句自己产品的短处的?

把选择权交给别人。

现实是, 大多数人特别是编程新手根本还不知道有"中文编程"这个选项, 或者是, 听到"中文编程"就认为唯一的选择是易语言. 也就是说, 对他们来说, 没的选. 推广的第一个, 也是中短期内个人认为最重要的目标, 就是让尽可能多的人知道"中文编程"的更多选项, 个人最关注的就是在所有主流英文编程语言中就可以使用中文命名这一选择.

@bldght 对很多观点不敢苟同.

我反对宣传,主要是反对对新手和外行人宣传。

#44 (comment) 最后已经说得很清楚, 我们是让他们了解更多选择.

如果新手是某职业,是要靠编程生活的,那么不应该向其推荐中文编程。

放心吧, 真正以编程为生的人, 不会傻到盲从用中文编程, 更何况是中文编程在处于明显的劣势地位的情况下. 至少在我看到的所有真正尝试了中文命名的例子中, 都亲身体会到了可读性提高的好处. 再提醒一下, 群众的眼睛是雪亮的.

我觉得现在的中文编程语言、工具链、生态环境,并不足以给新手谋生的保障,这样对新手吸引到中文编程,只会他们耽误他们职业生涯,浪费不必要的精力。

说到新手谋生, 我看到了太多从易语言起家的开发者, 而原本他们也许会迟很多才进入英文编程的门槛.
生态圈确实重要, 而使用中文命名恰恰是生态圈培育的一个重要辅助. 而现在大多数主流英文编程语言已经支持Unicode这一条件, 已经基本去除了中文命名大规模应用的障碍. 基于我在各种语言/框架中的实践, 只要框架本身支持中文命名, 没有发现任何由于采用中文命名导致的程序问题.

这样对他们是不负责任的。中文编程目前并不是一种选项。

建议你先看看对在代码中使用中文命名的质疑与回应, 假如你开发过业余项目, 相信你也碰到过无法理解自己写的的英文命名的时候. 而业余项目或者随手写的小工具恰恰是数量上最多也是门槛最低的. 在这些项目中用中文命名, 不但能节省自身精力, 而且还能因为节省的开发成本而促使更多业余项目能有更长足持久的发展, 发展成真正成气候的开源项目, 这些项目成熟后, 又可以促进企业对于中文编程/命名的信心, 从而进入商业项目. 这本身就是中文编程生态圈建立的一个最可行途径之一.

对外行人也是如此,他们不懂编程,告诉他们中文编程,很有可能引起他们不切实际的期待,并最终造成误解。

之前也说过, 如若发现我们的文章中有夸大不实成分, 请不吝赐教!

但对程序员,可以适当的宣传一些,可以吸引有兴趣的,有一定能力的同行,这对中文编程是有好处的。

这就是这个讨论组的初衷.

“酒香不怕巷子深”是永远不会过时的。改开以来,国人过于浮躁,干一些事,一定要大声宣传、吸引眼球,特别是互联网公司,一定要有策划,

呵呵, 相比起那些不择手段地反对中文编程的水文, 我只能说我们的宣传还是太保守了.

把素质参差不齐的人都吸引过来了,这对中文编程并没有什么帮助。

无论背景和教育水平, 对编程, 或者说让电脑完成自己想做的事这一需求是非常一致的. 而中文编程能够让更多的人更早也更容易地满足这一需求. 我认为这就是功德. 而更多人的参与, 只要是真心实意的探讨和切磋, 对中文编程都有百利而无一害.

我不知道这里的各位,推动中文的编程的目的是什么?是为名,是为利?如果是为名与利的话,那我可能不适合这里。

上面应该已经说的很清楚了. 另外, 在至今的所有讨论组成员中, 我还没有发觉一位是为了名利而参与的. 说白了, 就像很多前辈们经历过的, 这条路艰辛而漫长, 直至今日也没有看到明确的曙光. 反过来说, 假如中文编程已经是明显有利可图的方向, 以现在的风险投资一窝蜂追热点的劲头, 恐怕早就吹成个大肥皂泡了.
再退一步说, 就算是有人纯粹为了名利而参与了中文编程, 又怎样呢? 凭什么做中文编程的就必须做苦行僧呢?

对中文编程,我是深信是可以把中文思维和计算机编程建立密切联系的,是可以大幅度降底国人编程门槛 的。最终可以实现一种,只要认识汉字、母语为中文、懂基础数学知识的人,都可以进行中文编程的景象。当然这项工作并不是一蹴而就的。

不需要等. 现在这一秒就可以开始用中文命名进行编程. 如果你用的语言/框架不支持中文命名, 烦请告知.

我看到这里一些同道,进行c\c++\c#的中文编译器编写,进行vsc的拼音插件编写,我怀疑这些工作的实用性有多大?有人会在实际项目中使用这些工具吗?

引自这里:
"意义在于, 汉化后的语言对新手更友好; 反思关键词意义; 对设计新语言提供借鉴; 积累编译器实现经验等. 风险是, 维护的工作量; 关键词推敲等. 优势是, 有不少已有的尝试可以借鉴." 而且vsc的拼音插件编写时还使用了中文命名, 期间这些编译器汉化开发者对命名和关键词都有很多相关心得. 这些都是中文代码积累的第一步, 对中文命名的规范制定/推广和新的中文编程语言设计都提供了宝贵素材.

认为实现中文编程的当务之急是,挑出一些计算机或编程领域的核心词汇,重新逐一精细化汉化翻译。为什么?我认为目前的中文词汇,相对于母语为英文的人,我们吃了大亏。人的思维天生对具象的名词容易理解,对抽象的名词难理解。一些计算机词汇,在英文中,使用了大量比喻类比单词,这些单词多数是具象的,但我们的前辈翻译成中文后,就变得抽象了,比较thread,在英语做为名词的意思是”螺纹; 线; 线索; 线状物“,这些意思是非常具象的,但目前翻译成“线程",是非常抽象的,你能一眼理解这是什么意思吗?另外一种情况,thread在英语中是通用名词,但”线程"在中文环境中就变成了专用名词。以英语为母语的人,可以通过thread的日常生活的使用,更容易理解thread在计算机中的含义,但在中文环境中,我们只能在计算机领域,才能理解这个名词的含义,除此之外,“线程"在日常生活中,一无用处,这样一来,我们思维负担就更一些,所以我们以汉语以母语的人就吃大亏。相对线程,翻译成"丝线”就明显更好一些。

你太低估前辈们的翻译水平了. 也太高估英语关键词和英文自然语言的接近程度了. 没有任何一个不懂编程的老外会对thread的计算机含义一目了然. 而"线程"至少包含了'线'和'程'两个含义. 其中'程'只要对"进程"了解, 就能够联系起两者. 相比thread和process, 明显是中文术语更能体现他们的关联. 另外, 你真的认为这些术语是中文编程的障碍吗? **人为了学编程, 可以愿意背几百几千个英文单词, 这区区数十个已经约定俗成的常用中文术语还能难倒我们吗?
另外, #40 中, 所有讨论都是结合了现有术语和习惯的, 我们的宗旨不是标新立异, 而是从实践出发, 找到新老程序员都能接受的方案.

@bldght 再提醒一下, 以后像#40 (comment) 对帖子主题本身合理性的讨论的还是请到这里进行.

bus是英文环境中固有词汇,被人借用在计算机领域,在我看来,bus一词远好过”总线",bus不仅表达了这一概念的结构,还同时表达了这一概念的功能。

@bctnry#40 (comment) 之外, '总线'也是个公交线路的中文术语.

宣扬程序语言本土化,无异于闭关锁国!

commented

宣扬程序语言本土化,无异于闭关锁国!

@JerryChin 本土化等价于闭关锁国吗?那反对本土化是不是就卖国了?

@JerryChin 存在使用母语编程的硬需求, 这里就是通过各种技术手段满足这一需求

@nobodxbodon 我只是觉得程序语言应该是中性的,比如英语一样是全球通用的语言。但是注释可以是任意语言,这样是最完美的解决方案。强行使用中文语言编程,会引入不可预料的风险。

@JerryChin
汉语是国际性语言吗?

据人民网报道:著名法国汉学家白乐桑认为,汉语“正在成为国际性语言”。作此判断的关键在于,汉语正在逐步纳入当地的基础教育。“现在全法汉语学习者总数约10万,过半数的学习者是中小学生,这表明汉语被作为正规的科目纳入了法国国民教育体系,是一个很好的趋势。”数据显示,2016年法国有150余所大学,700多所中小学开设汉语课程。

另据美国汉语教师协会统计,全美中小学在学汉语人数占全部在学人数的2/3,达到40万人左右;英国现有12万中小学生在学习汉语,占全部在学汉语人数的60%;新西兰2010年仅有1万名中小学生学习汉语,2015年达到4万人,汉语成为增长最快的一门外语;意大利注册汉语学员逾3万人,开设汉语课的中小学过百。

英国名校切尔滕纳姆女子学院有160多年的历史。在切尔滕纳姆女子学院,汉语和法语、西班牙语一样,是7年级(相当于国内初中一年级)学生的必修课。从最初只有几个学生学汉语到如今汉语被纳入必修课,这反映出汉语地位的变化。每年学校学汉语的生源都很稳定。老师,曾经一个人带80名学生。那时学校有3名全职老师,由此估算,学汉语的学生200多名,相较于全校870名左右的学生,比例并不低。值得一提的是,越来越多的英国人加入到教汉语的行列中,一位牛津大学毕业的英国本土老师也在教汉语。

以法国为例,2016年法国约5.2万名中小学生在学汉语,是2004年的500多倍 。而在世界范围内,进入新世纪以来,许多国家汉语学习需求呈现“井喷式”增长。来自**国家汉办的数据显示,目前除**(含港澳台)之外,全球学习使用汉语的人数已逾1亿人。

以面向全球开展汉语教学、传播中华文化为职能的孔子学院,自2004年创办以来,孔子学院发展迅速。截至目前,已在全球142个国家和地区建立516所孔子学院和1076个中小学孔子课堂,各类学员210万人。尤其是党的十八大以来,5年新覆盖34个空白国家,新增116所
孔子学院、541个中小学孔子课堂。

5年来,全球孔子学院和课堂累计举办文化活动10多万场,受众达6000万人。

全球都在学汉语,其原因在于进入新世纪以来,**经济实力增强、政治影响扩大、国际地位提高,**道路、**模式的影响力和辐射力显著增强。

@JerryChin
世界各国普遍看好**发展前景, 汉语在国际经济贸易、文化交流过程中作用凸显,文化价值和实用价值不断提升,国际社会对学习汉语的需求越来越大,形成了前所未有的“**热”“汉语热”。

随着**的发展,到**旅游、投资的外国人增多,他们对**有了更多的了解,学习汉语的需求相应增加,他们也鼓励自己的孩子学汉语。

此外,在汉语学习者中,有相当一部分是因为掌握汉语是就业的加分项。现在美国越来越多的年轻人开始学汉语,因为“会增加就业机会”。

据美媒称,2005年,美国只有200所中学开设了汉语课,学中文的孩子只有两万人;如今,据不完全统计,美国学习汉语的人数已经有40万。

在媒体看来,中文的流行与**国际地位的提升不无关系——“**与世界各国在经济、政治、文化等多个领域合作交流的增加,令‘汉语热’逐步成为全球潮流。”

目前全球已有60多个国家将汉语教学纳入国民教育体系,”,“现在全球学习汉语者从2004年的近3000万人攀升至1亿人……其增长速度让人吃惊。”

在马来西亚媒体看来,学习语言的收益将超越语言本身的价值。“汉语是全球最流行的语言,全球说汉语的人数几乎是说英语者的三倍。随着**国力的提升,与之相互理解并减少误会对其他国家来说变得非常重要。”

美国有关部门认为,未来,美国在财政、商务、外交和安全部门,都需要精通汉语的美国人。巨大的市场缺口,使对外汉语教师供不应求。

如今,美国中产阶级家庭越来越热衷于雇佣懂中文的保姆,其年薪往往比一般的保姆要多出至少两万美元。即便如此,华人保姆仍然供不应求。美国彭博新闻社提到,前两年在纽约就曾出现两家雇主为了争一位华人保姆而相互抬价的情况。

在某招聘网站上,“汉语教师”的岗位每日更新达近百个。在国外,汉语教师的薪资非常诱人,据统计,在新加坡当汉语教师,年收入约为18万至36万元人民币,在美国约为6.5万至10万美元(约合人民币44万至68万元),在德国约为7万欧元(约合人民币54万元)。

汉语还是联合国的官方语言。

由此可见,根据不同需要,学习汉语成为了一个全球性的热潮,
汉语将为国际性语言的说法是有相当依据的,这也表明了中华民族和平崛起立于世界之林的一个显著标志!

@JerryChin 能说一下什么是用ascii以外的字符编程有的 不可预料的风险 吗?

commented

我只是觉得程序语言应该是中性的,比如英语一样是全球通用的语言。但是注释可以是任意语言,这样是最完美的解决方案。强行使用中文语言编程,会引入不可预料的风险。

@JerryChin 那么问题来了,对基于英语符号的编程语言,是中性的吗?现在的PL,明显对英语母语用户有优势,对非英语用户不友好,这跟全球通用不通用没关系。往大了说这叫文化帝国主义,凭什么所有人都要用英文编程?程序设计跟写代码是两回事好嘛。

真正完美的方案就是用以套完全中立的死文字,这样大家都没有优势,都需要从头学起。但这样有意义吗?编程语言就应该从实用角度出发,哪有什么不可预料的风险,你喜欢用英文而不用中文编程,对你来说还存在风险?

中文编程论战 之我见 - Woodpecker Wiki for CPUG ~ 10年前大家的嗯哼...

简单来说:

  • 编程语言不是自然语言, 强行汉化除了增加学习/交流/运行/调试/..成本, 并没有直接收益
  • 但是, 请注意:
    • 程序猿, 是唯一一种以消灭本身职业为最高追求的物种
    • 即, 我们一切的努力只是为了不再编程, 随便说一说, 一个眼神儿, 或是嗯哼一下
      • 电脑就能理解, 并自动生成新的指令/代码/服务/硬件/... 为我们服务
  • 所以,整体上:
    • 对中文编程的质疑 ... 讨论方向从根儿上就歪了...
    • 应该是: 如何令电脑理解中文? 无论文字还是语音?
    • 期待的可能成果是一种通用中间件:
      • 可以解析中文文本/语言
      • 转化为任何一种编程语言都可以理解的语法结构
      • 供给其它语言转换/调用...
  • 比如, 初级形态:
    • 可以是一组 IFTTT 触发器
    • 只要识别出 2~3 个关键词
    • 就可以完成匹配为开始为我们服务
  • 否则, 想直接用中文进行编程活动, 是不科学不现实不**不智的...
    • 而应该是试图将中文变成一个自然指令界面.

是也乎,( ̄▽ ̄)

@ZoomQuiet 多谢分享! 时区问题只能明早再详细回复, 不过对IFTTT等等思路很有共鸣. 之前也有类似想法 - 知乎

@nobodxbodon 是也乎,( ̄▽ ̄)

  • 所以, 中文编程 这词的解释和引导姿势, 导致了大家的智能无法简单的共创起来
  • 因为, 从根儿上, 中文几乎看不到什么科学的工程化的方法来真正令编程理解:
    • 不象拼音类语言, 每个事物都有有限的专用单词进行一一指代
    • 中文从一开始就用另外一个方向的架构来解决了语言永续问题:
      • 使用足够大的基础元素
      • 设计足够灵活的语法
      • 结合发音和形状
      • 可以自由组合出无限意义
    • 这导致每年其它语言创造几十万新字, 也遗忘更多数量的
    • 只有**永远在相同字基础上, 无限创造出新词来...
    • 这也直接导致对中文, 自然语言的解决几乎不可能单从文本本身就可以完成:
      • 必须同时考虑
      • 发音
      • 字形所指的画面
      • 字义在上下文的变化
      • 以及以上的多种组合
      • ...
  • 这也就导致, 用中文文本来编程:
    • 从行文上无论阅读还是理解都异常反直觉
    • 从本质体验上违反了程序给电脑看的设计目标
  • 但是, 随着电脑可以控制的事物越来越多
    • 普通人, 非专业人士, 想通过某种界面/渠道/形式来控制自身周围的电脑
    • 这种期待是自决和持续增长的
    • 但是, 解决这种问题并不是编程中文化
    • 而是将中文带入语音输入界面世界之类...
      • 可以帮助普通人不用编程
      • 就能享有程序猿的创造能力
  • 这才是应该的努力方向...
commented

@ZoomQuiet 你说的这些其实没那么复杂。我觉得只要先把底层替代了,问题就好搞了。个人觉得第一步还是应该先做输入法。

commented

我来总结一下 @ZoomQuiet 的观点:

简单来说:

  • 编程语言不是自然语言, 强行汉化除了增加学习/交流/运行/调试/..成本, 并没有直接收益

第一,汉化未必会增加学习/交流/运行/调试等成本,且存在直接收益

  • 但是, 请注意:
    • 即, 我们一切的努力只是为了不再编程, 随便说一说, 一个眼神儿, 或是嗯哼一下
      • 电脑就能理解, 并自动生成新的指令/代码/服务/硬件/... 为我们服务

第二,这里存在一个误解,就是把coding理解成了programming。按照z大妈的说法,其实应该是programming应该消灭coding

  • 对中文编程的质疑 ... 讨论方向从根儿上就歪了...

第三,是的,很多人偏见从一开始就是歪的

  • 应该是: 如何令电脑理解中文? 无论文字还是语音?
  • 期待的可能成果是一种通用中间件:
    • 可以解析中文文本/语言
    • 转化为任何一种编程语言都可以理解的语法结构
    • 供给其它语言转换/调用...

第四,这个描述,和我设想的DSL是一致的。

  • 比如, 初级形态:
    • 可以是一组 IFTTT 触发器
    • 只要识别出 2~3 个关键词
    • 就可以完成匹配为开始为我们服务

第四分之一,IFTTT本质上就是DSL

  • 否则, 想直接用中文进行编程活动, 是不科学不现实不**不智的...
    • 而应该是试图将中文变成一个自然指令界面.

第五,谁能说编程是科学?编程不过是一种技术手段,背后的科学计算机科学等/数学不算科学。中文编程没有任何所谓的伪科学成分,所有认为中文编程是民科的言论从根本上都是站不住脚的。

commented

续上,第二部分总结:

所以, 中文编程 这词的解释和引导姿势, 导致了大家的智能无法简单的共创起来
因为, 从根儿上, 中文几乎看不到什么科学的工程化的方法来真正令编程理解:
不象拼音类语言, 每个事物都有有限的专用单词进行一一指代
第六,中文的抽象能力,或者说,在symbolic这方面,恰恰是吊打所有字母语言的。Ken. Iverson曾通过APL指出了【notation as a tool of thought】的必然性,这种恰恰提供了中文信息化的基础理论支持。编译原理因为历史原因基于了字母+空格的分词方式,然而,这并不代表中文/文言文解析不可行。
中文从一开始就用另外一个方向的架构来解决了语言永续问题:
使用足够大的基础元素
设计足够灵活的语法
结合发音和形状
可以自由组合出无限意义

第六分之一,这段描述,本质上和编程的抽象过程是一致的。

这导致每年其它语言创造几十万新字, 也遗忘更多数量的
只有**永远在相同字基础上, 无限创造出新词来...
这也直接导致对中文, 自然语言的解决几乎不可能单从文本本身就可以完成:
必须同时考虑
发音
字形所指的画面
字义在上下文的变化
以及以上的多种组合
...
这也就导致, 用中文文本来编程:
从行文上无论阅读还是理解都异常反直觉

第七,这个推断的逻辑是站不住脚的。文言文就是很理想的解析模型。

从本质体验上违反了程序给电脑看的设计目标

第八,这取决于中文DSL的设计方式。并不是所有的设计都违反了视觉可读性。相反现在所谓的可读性代码,实际上是不可读的(即你没办法一句话念出来,因为这里面通常涉及到结构化文本)

但是, 随着电脑可以控制的事物越来越多
普通人, 非专业人士, 想通过某种界面/渠道/形式来控制自身周围的电脑
这种期待是自决和持续增长的
但是, 解决这种问题并不是编程中文化
而是将中文带入语音输入界面世界之类...

第九,这里还是体现出了,编程和写代码两者概念的混淆。讲中文引入编程一点问题都没有,至于是否应该用中文写代码,个人保持中立观点。

可以帮助普通人不用编程
就能享有程序猿的创造能力
这才是应该的努力方向...

第十,事实上这就是现如今中文编程正在努力的方向。

@Absente 是也乎,( ̄▽ ̄)

嗯哼, 虽然通过邮件回复也可以进入 Issue 的回复桟, 但是 md 排版就丢失了,
所以, 俺回到 issue 回复, 暂时无异议的就不回复了..
使用残缺的 bottom 回复形式.

第一,汉化未必会增加学习/交流/运行/调试等成本,且存在直接收益

  • 这其实是争议的核心
  • 讨论的对象是 用中文输入法和字符作为程序文本的编程行为
  • 那么其直接收益在哪儿?
    • 目测只有 不懂编程的产品经理们有看代码的勇气了, 当然其结果照样是悲剧的...
    • 学习: 以往所有教材得全部重新编写, 所有概念也可能要重新定义, 因为中文关键词和概念相同的话, 将撞到概念和运行时以及编译时多种状态中不同物件相同名指代的情况
    • 交流: 和国外程序猿交流, 毕竟主要的几个社交编程平台都是外国的, 英文为主
    • 运行: 最终系统运行的还是机器码, 或是说汇编, 中文代码多一层编译到正常 ASCII 代码才能进入编译流水...这是运行时效能的破坏...进一步的中文字符占有空间也大2~8倍...
    • 调试: 为了将出错信息也变成中文将极大的提高代码解析回溯的复杂度...

第二,这里存在一个误解,就是把coding理解成了programming。按照z大妈的说法,其实应该是programming应该消灭coding

...

第九,这里还是体现出了,编程和写代码两者概念的混淆。讲中文引入编程一点问题都没有,至于是否应该用中文写代码,个人保持中立观点。

  • 以上是过往讨论中反复混淆点之一
  • 这本身也证明了汉语在进入 IT 时代时, 受到日本等等文化的影响
  • 并没有完全适应高速发展的 IT 技术, 翻译过程本身并没有太多程序猿参与
    • 各种重要/关键技术图书,都是一千字10元的清华外语系学生们的作品
    • 持续又给中文技术界引入/隐藏/埋下了越来越多的坑...
  • 不过, 这里 @Absente 已经自我矛盾了:
    • 至于是否应该用中文写代码,个人保持中立观点

    • 对照: 汉化未必会增加学习/交流/运行/调试等成本,且存在直接收益
    • 那这个中立就很奇怪了...

第五,谁能说编程是科学?编程不过是一种技术手段,背后的科学计算机科学等/数学不算科学。中文编程没有任何所谓的伪科学成分,所有认为中文编程是民科的言论从根本上都是站不住脚的。

  • 这是俺的不严密了
  • 编程是种实践行为, 受到科学原理的制约
  • 但是,本身并没有形成可以证伪的科学研究体系或是理论
  • 不过, 编程语言本身是在科学研究范畴的:
    • 有 PL ~ 编程语言学科, 珢神就是其中一位
    • 以及数据库/算法/语言学/...各种学科分支的融合点在深入编程实践活动的各种层面
  • 中文编程 ~ 或是严格的说: 基于中文输入法并将汉语字符作为程序主要文本的编程行为
    • 这一追求是毫无道理的
    • 除非象有次 007 电影中设计的, **军方电脑从硬件到OS 一切都是中文的, 键盘都是专用的
    • 那样的话, 用中文才有意义
    • 否则, 只是一层CSS 而已, 除了能令有关领导欣慰, 对中文世界的编程水平并无任何正面影响
    • 因为, 即使无论哪个层面都作到位了
    • 基于中文输入法并将汉语字符作为程序主要文本的编程行为 成为一种可靠的选择项了
    • 依然对 普通人能不用专业长期训练, 就可以通过编程来解决遇到的现实问题 这一目标没有什么帮助
    • 甚至于是反效果,毕竟这个世界上英文为主的程序文本占主体, 增长也最快:
      • 中文编程 想达到和英文编程行为可以平等对话
      • 那至少 中文编程 交付的软件项目 GPD 能达到 英文编程GDP 的40% 以上
      • 这几乎是不可能的...无论从成本和时间上来推想
      • 因为芯片厂商根本就没这种动力...

第七,这个推断的逻辑是站不住脚的。文言文就是很理想的解析模型。

  • 文言文形式的确接近程序
  • 问题在, 文言文 本身已经从日常交流中退出汉语场景了
  • 那么, 用回类似的文体, 虽然理论上有希望确保严密性
  • 但是, 从 学习/交流/运行/调试/... 方面不就又违反了初衷?

...

可以帮助普通人不用编程
就能享有程序猿的创造能力
这才是应该的努力方向...

第十,事实上这就是现如今中文编程正在努力的方向。

  • 等等, 从首页链接的各种尝试方向看根本没这个倾向哪
  • 所有项目都是在和各种流行语言的解析器叫劲, 少数刚刚敢摸编译器
  • 至少没有任何一个 中文编程 的实践作品可以帮助普通人越过 coding 过程
    • 直接享用 programming 的成果

是也乎,( ̄▽ ̄)

commented

@ZoomQuiet 时间有点晚了,我就挑几点回复:

不过, 这里 @Absente 已经自我矛盾了:

第一,这里并不矛盾。个人是把中文编程和中文coding区分开的,所以,我支持中文编程,但对中文coding中立。btw,coding is low level programming。

第二,关于[直接收益]的问题,一两句话肯定说服不了你。这个回头再补充。

有 PL ~ 编程语言学科, 珢神就是其中一位

第三,说个极端点的表述,我个人认为PLT,才是真民科。

问题在, 文言文 本身已经从日常交流中退出汉语场景了
但是, 从 学习/交流/运行/调试/... 方面不就又违反了初衷?

第四,文言文不是义务教育阶段都会了吗?不会就继续coding呗

等等, 从首页链接的各种尝试方向看根本没这个倾向哪

最后,为了证明DSL的可行性,我已经开了repo,等成型了我会邮件通知您。

https://github.com/program-in-chinese/flo

@ZoomQuiet 刚拜读了前作. 对其中几点很有同感:

  • "要增加代码的可重用性,要从下面几点着手"中的几点. 之前有个讨论贴也试图总结语言/IDE需要的特性.
  • "全中文, 也强烈的 促使了类,函式,变量命名的统一! 明晰! 保持思路简练!" -- 个人认为母语命名还需大力普及, 尤其是在现有编程语言环境中(即使没有汉化语言, 母语命名也有增强可读性的优势). 个人在组中开的绝大多数项目也都是用中文命名的. 国内也有不少实践(在v2ex的这帖搜集了一些), 尤其是传统业务相关领域, 就像这贴所言, 传统行业的信息化还有很多欠账要补, 而业务相关的代码是最能够从母语命名获益的.

而是将中文带入语音输入界面世界之类...

同感: 从人机交互角度看中文编程:'打开微信'. 个人认为确实是个很大的应用方向, 欢迎开新issue讨论. 不过语音输入也要转化为文本, 之后就是一个编译过程了. 之前尝试过设计比较简单的日常事务处理语言.

@Absente #99 (comment)

另外附上一则评论,供参考:

如果指的是那篇自述文, 如有意见建议请在这里明示. 毕竟有时旁观者清.

commented

@nobodxbodon

前文:https://zhuanlan.zhihu.com/p/48272342 《专栏一岁了-我为什么投身于普及用中文编程
上文:https://www.v2ex.com/t/503773 《我就知道很多人会黑中文编程

下文/评论节选》

just for fun 没问题,只是总有些中文编程布道师,打着国家民族的旗号的,搞些意义不明的事,误人子弟,这种人不狠狠黑一下对不起我一颗真正的爱国心。
你不和这些人划清界限,客观来说躺枪是难免的。

@Absente 我想听的是你的意见/建议. 类似的评论之前已经看到了

commented

@nobodxbodon 我的观点:通过一种通用的、符合中文逻辑的programming language或programming notation,来进行编程/演示说明。在其中加入中文命名。而不是把中文编程和中文命名笼统的放在一起。

这是基于现状考虑的,因为很多人看到中文编程就觉得,啊,有时一个民科/骗钱的。

背景参考:
1 通过非语言特定的编程语言加上中文命名,来推广中文编程》#101
2 中文编程的迷思》https://zhuanlan.zhihu.com/p/31347861
3 DT:一种兼容手写的programming notation》pyzh/clo.DT#1
4 CPN-2:代码与抽象结构设计》pyzh/CPN#3
5 CPN-1:CPN-1:基础语法设计》pyzh/CPN#1

关于翻译,我的观点和《中文编程的迷思 类似,有用,但是现状是用处不大,甚至必要性不充分。翻译这块,所以个人能做的最简单的也只是API再封装,这样成本小一点。

关于代码翻译的问题,不如换一个角度,比如:真正阻碍非英语用户编程的是什么?

我觉得这个问题,如果只是想帮助看不懂代码的人更容易读懂代码,完全可以借助 [插件/预览] 这种形式,没必要对代码本身直接进行改动。相反,是否用中文命名重构代码,应当把决定权放给使用者。

个人认为,很多人看不懂代码,主要两方面,1是他不知道这套符号在做什么 2是他能读懂了这套符号但是不知道这套符号实现了的东西具体对应怎样的业务逻辑。

假设有一段代码(¥#¥&#&¥#&¥)/记为A,它在普通人的阅读理解过程中,实际展开是这样一个过程:1哦原来是一个list comprehension,2哦原来这个写法直接实现了quicksort,3哦原来这个代码是把数据表按班级分组排列的意思

假设在不看教程的前提下)同样的代码,如果我们把java的实现记为B,把APL的实现记为C,B和C的展开过程有相似的地方也有不同的地方。

不同的地方:B1过程中,涉及到很多java的语法,于是不懂的需要去查文档;之后又会看到很多不同的库以及对应的用法,不懂的又需要查文档。但是在B1B2过程中,假设变量都是英文单词,那么对于小白来说,这个干扰因素存在了3个主环节+2个分支环节。

APL的语法不复杂,所以查文档只有查字典着一个环节,另外APL代码搞定快速排序只需要一行鬼画符,没有英文单词的干扰,所以不懂的只要查字典,然后展开表达式就可以了。

当然,如果使用者只是想调用这个函数,那么主要的问题就简化了:流程B只需要理解参数类型和返回值类型,然后记住quicksort(哪怕看不懂单词也不影响)。而APL只需要复制粘贴重命名快排

相同的地方:都需要先理解一套notation,然后理解这套notation背后在做什么,再把这套逻辑抽象映射到业务上。

简单说,我觉得与其直接翻译代码,不如生成翻译过的代码结构映射、逻辑流程映射、以及API文档

当然一下子翻译三个东西太多了,也没必要。个人认为可以先把三者统一起来,目前能想到的最简单的方法:

假设有一段代码(伪java)


public class HelloWorld{
privrate void echo(String s){
  System.out.println(s);}

void output(String s){ echo(s);}

public static void main(String args[]) {
  output("hello world")
}}

假设我已经做好了一个专门处理代码翻译的vscode插件,这时候,有一个[显示:翻译/中文]选项,里面有几个子选项/多选:1 翻译常用词 2 翻译生僻词 3 翻译关键词 4自定义/常用,而4里面,又有 4.3.1 翻译常用关键字 4.3b 常用关键词除外 4.0 自定义

假设我是个对java语法有了解的新手,这时候我选择:显示[不翻译keyword+翻译常用词+不分词翻译],那么得到的结果应该是这样子:

public class HelloWorld{  //因为没有分词
privrate void 回显(字符串 s){
  系统.输出.打印行(s);}

void 输出(字符串 s){ 回显(s);}

public static void main(字符串 参数表[]) {
  输出("你好 世界")
}}

假设我是一个老手,但是英语比较差。想在兼容代码的同时,借助中文命名提升效率。这时候我可能会选择:翻译/改动[检查依赖+翻译所有词+启用分词翻译+不生成辅助代码],那么结果应当是:

public class 你好世界{
privrate void 回显(String s){
  System.out.println(s);}
void 输出(String s){ 回显(s);}
public static void main(String 参数表[]) {
  输出("你好 世界")
}}

基于上一个假设的前提,再假设我比较懒,启用了[生成辅助代码],那么结果应该是:

class 辅助{
public 系统输出打印行(...s){
  System.out.println(s);}}

public class 你好世界{
privrate void 回显(String s){
  系统输出打印行(s);}
void 输出(String s){ 回显(s);}
public static void main(String 参数表[]) {
  输出("你好 世界")
}}

这个时候,完全可以把回显系统输出打印行合并到辅助里面。

举例就先到这里。总的来说,基于插件的代码翻译,还是要实用为主。如果做翻译插件,可以先做显示层的remap,再做批量中文命名,再做modeling output

而在具体的翻译这块,也可以部分融入拼音的元素在里面,把拼音命名或拼音缩写展开成中文

关于[生成翻译过的API文档],个人觉得可以按需翻译,这样个环节,和输出代码结构有不少交集,相当于把外部依赖都罗列清楚了

最后,关于[真正阻碍非英语用户编程的是什么]这个问题,其实是个比较复杂的问题,故不在此赘述

@Absente 关于代码翻译的技术细节可以另行讨论.

我在意的是, 在两个帖子(包括在你发v2帖之前我的自述文在v2的转帖讨论)中, 有数百条回复, 且不说正面建设性的回复也不少, 在负面回复中也有值得借鉴的部分, 而你挑了这条有离间色彩的专门转帖到这里让我参考, 我需要明白你看到的参考意义是什么.

commented

@nobodxbodon 明白你的意思了。那段话可能是有一点分裂的意思,但我的理解是,用中文的逻辑编程,和用中文写代码,确实是两个topic。而现状是,统一用中文编程的名号对外宣传,在没有说服力的项目出现之前,宣传上遇到的阻碍会越来越多,毕竟刻板印象的人还是太多了。所以我现在的策略是,编程语言的设计,先做符号化/符合中文逻辑的通用形式即可。而中文命名则无须多言,需要用多少用多少。

所以那段话主要的参考意义,需要结合那个[概念划分]的issue的语境来参考。中文命名的阻碍只有一个,就是输入法。而中文式的编程语言的阻碍,则是整个西方的CS体系。

@Absente

那段话可能是有一点分裂的意思

除去那段话中对我的含沙射影, 我的理解是它试图把中文命名从中文编程中割裂出来. 与此相关最典型的一种言论就是, 没有成熟的中文语法的编程语言之前, 使用中文命名是无关紧要或没有意义的.
个人认为推广因地制宜地(在现有编程语言中)使用中文命名不仅有短期效益, 也可以促进中文语法的编程语言设计.

用中文的逻辑编程,和用中文写代码,确实是两个topic

请详述什么是"用中文的逻辑编程"? 个人认为业务逻辑是程序逻辑中最重要的部分之一.

中文命名则无须多言,需要用多少用多少

我看到的情况是, "命名只能是英文的"这一想法还非常普遍, 我的短期目标就是转变这一想法.

commented

没有成熟的中文语法的编程语言之前, 使用中文命名是无关紧要或没有意义的.

@nobodxbodon 我觉得更多人的对中文命名的接受程度,取决于IDE或输入法对中文输入的友好程度。更多的人应该是认为:汉化关键词的意义是最小的,其次是翻译代码,最后是中文命名。

关于[用中文的逻辑编程]这点,先说什么是反例吧。我觉得[for in]这种语法就是用英语的逻辑去编程,而prolog则是用数学[解题/回溯]的思路去编程。关于具体什么[中文的逻辑/编程],这方面的内容我还没有准备充分,等有了足够完善的内容再补充。

关于["命名只能是英文的"这一想法还非常普遍],我认为主要是3点。1是输入法问题,这一点不经体现在编写代码的时候,同样体现在部署程序的时候,比如linux无GUI的情况下需要修改代码,这时候没有中文输入就很尴尬。 2是刻板印象,当然另一方面,很多编程语言工具确实对unicode支持不到位。3是文化帝国主义的问题

@Absente 如果你转帖那条评论只想说明"不少人对中文命名仍不以为然"这一事实, 请在今后类似转帖时说明清楚, 以避免不必要的误会. 如我之前所言, 在数百条评论中专挑此条拿来参考, 难免让当事人有其他联想.

@nobodxbodon 程序语言的语法和自然语言无关。不是支持多种语言的token,而是各种token的名字不存储在源码里,源码里放token id之类的东西,ide显示源码时按语言包显示。

想法一致。这样能实现国际化的母语编程,甚至是个性化语言编程。

@mandolin 很难找到一种适用于不同语种的"自然语言无关语法". 即使语言设计者/团队对多种自然语言都有相当水平, 也会导致一些不得已的折中, 最后的结果很可能是一个既不贴近中文语法, 又没有什么国外开发者认可的四不像项目.

举个简单的例子, 如这里提到的, 常见的for 某项 in 列表语法, 对应到中文就很难找到完全符合同样语序的. 对于 某项 在 列表仍然不符合中文习惯用法, 而对于 列表 中 某项就好的多, 但对应英文又挺难办了.

这还仅仅是中英两种语言, 如果是语法相差更大的语种, 可想而知这种编程语言语法设计的难度会有多大.

@mandolin 很难找到一种适用于不同语种的"自然语言无关语法". 即使语言设计者/团队对多种自然语言都有相当水平, 也会导致一些不得已的折中, 最后的结果很可能是一个既不贴近中文语法, 又没有什么国外开发者认可的四不像项目.

举个简单的例子, 如这里提到的, 常见的for 某项 in 列表语法, 对应到中文就很难找到完全符合同样语序的. 对于 某项 在 列表仍然不符合中文习惯用法, 而对于 列表 中 某项就好的多, 但对应英文又挺难办了.

这还仅仅是中英两种语言, 如果是语法相差更大的语种, 可想而知这种编程语言语法设计的难度会有多大.

可能我们说的不是一个点。

打个比方,实现这种机制后,同一套源码(但一般不需要开发者直接面对),而IDE通过一套(对应或转换)机制,可以让你在你的IDE里用中文编程,我在我的IDE里用类C语言语法,另外一个人用西班牙文自然语法。
重点是,如果你觉得“官方中文配置”很拗口,那么你自己可以定义一套。如果我跑到你的机子上要做个演示或者临时用一下,只需要把我自己的配置加载上去,立马就可以用我自己的方式写代码。而底层源码却是始终是同一个。

也就是说,并没有一个类似“易语言”的钦定语法(绑架了所有人,实际上目前的所有语言都是如此),每个人都可以自己定义一套符合自己习惯的语法语序,在你的IDE里,可能是形式是:循环 3000次:做点事,在我的IDE里则可能是:给我做点事=>重复:3000次

再打个比方,易语言或者其它中文编程语言,本质上是新作了一套语法,而HAXE类似于在英语汉语等世界各大语言之外做了一套世界语(并以此为中心语言做转换)。而上面说的这种这种方式,则是做了一个翻译机。

所以说,你第一段话所担心的问题其实是不存在的。
实际上在这种编程环境下,我写了一个程序,源码发给你,你不会知道我是用某个“典型中文语法”还是我自己定义的一套。类似我发了个txt给你,你无法确定我是否一定是用记事本写的。

或者这样说可能更清楚了:
针对当前的某种语言比如说java
最开始我们都用记事本。同一个工具,同一套语法,同一个源码。
接下来我们开始用不同的IDE。不同的工具,同一套语法,同一个源码。

某天,最后只剩下(底层)源代码是同一个(但我们基本不直接面对它)。

当然这套机制实现难度肯定很高,因为涉及到语法语序的全面兼容。但我觉得比做翻译机要容易得多,因为(可能不好表达,这里只能简单说说。):用于人来交流的自然语言的形式是不可控的,和语境有关系,而社会语境是无限的;而针对编程开发所需要的语言体系,即便有语境问题,但这里的语境一定是有限和可控的。

@mandolin 谷歌翻译?

@mandolin 谷歌翻译?

未来的谷歌翻译(或者XX翻译)。

@mandolin

某天,最后只剩下(底层)源代码是同一个(但我们基本不直接面对它)。

现在的编译器前后端设计就已经提供了定制前端的机制吧. 没看出需要额外开发的架构.
落实到实现, 还是针对每个自然语言设计语法, 以及整套标准库的设计/命名.

@mandolin 很难找到一种适用于不同语种的"自然语言无关语法". 即使语言设计者/团队对多种自然语言都有相当水平, 也会导致一些不得已的折中, 最后的结果很可能是一个既不贴近中文语法, 又没有什么国外开发者认可的四不像项目.

举个简单的例子, 如这里提到的, 常见的for 某项 in 列表语法, 对应到中文就很难找到完全符合同样语序的. 对于 某项 在 列表仍然不符合中文习惯用法, 而对于 列表 中 某项就好的多, 但对应英文又挺难办了.

这还仅仅是中英两种语言, 如果是语法相差更大的语种, 可想而知这种编程语言语法设计的难度会有多大.

for elem in list 的例子不好,不具有普适性。比如 PHP 用的 foreach ($list as $elem) 就不会让西文用户感到不适应。

@darkcmh #40 (comment) 中提到一些推广相关的非技术问题,感觉也许在这讨论更方便。技术相关的部分还请继续在那边讨论。

这套规范和对应功能还要能堵上那些嫌切换中文输入麻烦的假洋鬼子的嘴

个人认为从自身(中文编程用户)角度出发考虑设计即可。因为设计再好的命名规范也拦不住一句”中文输入比英文麻烦“。相当大比重的反对声是为了反对而反对。

这样做首先能避免一些原来就抵触中文编程的人嘲讽只是翻译了一下现有编程语言的关键字以落人口实

同上,尽量从自身考虑为好。任何一点语法相似性都可以被拿来说事。这种过去近二十年都不断被攻击的点上,大可以不去理会。当然,对于”摒弃原有的照搬式的类C编程语言的方式,只能在一定程度上借鉴“,个人完全赞同。

单纯的问问用中文的目的何在。。
各位能用明白github,用英文编程应该没问题的,为什么非要用中文(doge)
更别提乱码等一系列老生常谈的兼容性问题。。。

commented

@Quandong-Zhang

单纯的问问用中文的目的何在。。

为何多数听到中文编程的第一反应就是效率不如英文编程? - 流星暴雨的回答 - 知乎

因为有些人说编程不需要英语

只需要认识关键词就行了

但当你问他库全是英文方法变量名怎么办,看不懂英语文档怎么办,英语阅读速度慢怎么办,找不到合适的英语词汇怎么办

会得到这样的回答:你不会英语还编什么程?

(以上来自于知乎真实回答)