-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
专用帖: 对中文编程的质疑, 困惑, 批评, 吐槽请到此处 #44
Comments
@ice1000 关于program-in-chinese/Java#1 (comment) 提到的, 个人理解如下: |
虽然暂时这里还算清静, 但迟早宁静会被打破. 其实有点意外, 在知乎上我感觉已经立了挺大一个flag但到现在还没有直接拍我的. 在可能出现的潮水中, 还望各位尽量遵循守则. 当然对于前来无理捣乱的也将直接处理. |
主要是有很多很垃圾的人也在倡导这些,比如C#前几天那个闹得特别大的大新闻 |
再补几句. 中文编程的路注定不会平坦. 对它有兴趣的开发者现在肯定是少数, 愿意以开源的形式进行尝试实践的开发者就更少. 这里希望能够集合各种对中文编程的不同方面的思路和实践. 这里列出的至今总结的所有四个方面都各有意义, 相辅相成. 门户之争, 以及各种形式的鄙视链会把原本就寥寥的力量更加分裂. 个人希望尽量避免. 而对于本组之外的有类似目标的声音, 即使不能接纳到组里, 一旦决定参与讨论, 尽量是从他们所述的有理的部分加以尽量客观和就事论事的论述, 其他自己不认同的部分只要不触及底线就不予碰触, 也正是我在那个汉化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 原始結構中的半角括號、半角花括號與半角分號,全都拿掉了,刻意體現出一種異化的感覺),可能有點誇張——或者說戲劇化——了。之所以看上去有些怪,可能是因為表意字符(例如中文裡面的字)與編程裡面用到的一些符號(例如半角括號、半角等號)放在一起,給人一種視覺上的張力(或者說叫人有些緊張),當然這個問題可以通過字體與排版等手段來緩解,我認爲不太適合當作反對中文編程(或者反對用某種非英文的語言來編程)的理由。 另外就是,如果把中文換成其他語言,例如日文、韓文、德文、法文,乃至拉丁文、梵文(如果我可以這樣胡亂舉例的話),那會不會出現這些問題呢?(當然這一段話,尤其是用最後那兩個語言來舉例,完全是我空想的,或許沒辦法和現實對應起來) |
刚找到了第一张图的出处: 四年前的如果计算机是由中国人发明的,那么编程时写代码会是全中文吗? - 田雅夫的回答 - 知乎 相信原作者的玩笑成分为多. 而前文中的第一个易飞扬代码(来源), 明显有较强的可读性, 以至于都不敢拿同样功能的英文代码进行比较. 因此后文直接删除了, 以更复杂也更难以一目了然的易语言程序代替. 加了一句 全文的中心似乎是"中文并不适合现有的编程方式", 后面的"未来的发展可能超出你的想象"也是画饼而已. 最大的意外是, 后面竟然提到 后文的问题又提到:
再看看下面的多数评论对中文命名还是基本反面态度, 说的基本是汉字输入慢, 会有莫名问题, 没规范等等老生常谈. 在腾讯看到另一篇转载, 评论区看到熟人哈, 也看到其他不少对中文编程支持的声音, 不过没什么对中文命名的探讨. 另外, 更早的一个版本中, 用的是"言语", 还有一些错别字. 在后续版本里都修正了, 也是颇为用心了. 前文中有的部分:后文中被改成了Java, 和更复杂的易语言代码:前文中有的代码示例, 后文中被删去了.:@jeffreybaoshenlee 现在看来, 它不仅是黑中文编程语言. 蛮意外的是中文命名被提到台面上了, 而之前看到的绝大多数关于中文编程的网文都只关注易语言为主的中文编程语言. 无论这一波讨论的推手动机如何, 至少中文命名已经成为了中文编程中不得不提的一个方面吧. |
@nobodxbodon 其實中文命名,在某種程度上,可以說有着令我意想不到的優勢。 因為英文標識符(包括變量名、常量名、宏名、函數名)如果是由多個單詞(word)所構成的詞組或短語(phrase),那麼就涉及怎樣分隔這些單詞的問題(例如是用下劃線,還是用連字符,或者把每個單詞的首字母大寫,形成所謂駝峰式效果)。 中文裡面,似乎可以暫時不考慮這個問題(真的不用考慮嗎?我不確定,我再想想)。例如剛纔最後一張圖的 另外,如果不談拼寫,只談命名,那麼有些程序——尤其是開發者基本上全都是採用某一種自然語言(例如中文)的那些程序——似乎更可以考慮用當地的語言來寫。 |
亂碼怎麼辦,昨天部門會議報告了中文檔名的解決方案,今天上午處理客戶問題又看到彈窗亂碼. |
又发现一个带节奏的知乎问题, 忍不住又回复了: https://www.zhihu.com/question/280213529/answer/445585014 @jeffreybaoshenlee 同感! 当然会有个歧义的问题, 但应该是比较容易规避的. 其实我觉得很神奇的是, 中文命名纵然有着各种优势, 竟然在大多数编程语言都支持Unicode十多年之后还没有在国内大规模使用. @shyangs 欢迎. 中文编码问题存在了几十年, 中文编程不是为它而生的, 但肯定能促进编码问题的发现和解决. 像你提到的问题, 恐怕要从系统默认编码和编程语言工具编码方式入手诊断, 有个也许类似问题详见 #26 和https://zhuanlan.zhihu.com/p/30008480) |
@bldght 感觉#41 (comment) 更属于这里. 有兴趣的话不妨在这里继续, 在那里恐怕会歪楼.
什么属于"主动推广"? 我们这个讨论组和知乎专栏算吗? 那怎样是"被动推广"?
个人还没发现任何一家敢打着中文编程旗号的公司做着挂羊头卖狗肉的事情. 现在群众素质都高, 只要胆敢冒头的, 一旦被发现猫腻, 肯定早就被唾弃了. 如果你有发现, 烦请告知. 反过来, 像上面发现的水文(详见最近一波对中文编程(包括中文命名)的攻势)可是(十)数年如一日地对外行人和新手进行欺骗性宣传.
恶名已经够多了, 再没有团结起来的力量进行尽量的正名和推广, 激浊扬清, 中文编程的大势还会被推迟.
做和说没有矛盾. 酒香不怕巷子深是理想而不是现实.
这也是我们一直尽量在做的. 如果你看到这里或者知乎专栏文章中有夸大不实/道德绑架的成分, 请不吝指出. 但是, 像上面的水文, 摆明了操弄各种误导手段对中文编程进行丑化. 那么, 在我们的对外推广宣传中, 只是侧重自己的客观长处而已, 何况短处也都提了, 已经相当君子了吧? 退N步说, 请问你看到过哪家广告会提到哪怕一句自己产品的短处的?
现实是, 大多数人特别是编程新手根本还不知道有"中文编程"这个选项, 或者是, 听到"中文编程"就认为唯一的选择是易语言. 也就是说, 对他们来说, 没的选. 推广的第一个, 也是中短期内个人认为最重要的目标, 就是让尽可能多的人知道"中文编程"的更多选项, 个人最关注的就是在所有主流英文编程语言中就可以使用中文命名这一选择. |
@bldght 对很多观点不敢苟同.
#44 (comment) 最后已经说得很清楚, 我们是让他们了解更多选择.
放心吧, 真正以编程为生的人, 不会傻到盲从用中文编程, 更何况是中文编程在处于明显的劣势地位的情况下. 至少在我看到的所有真正尝试了中文命名的例子中, 都亲身体会到了可读性提高的好处. 再提醒一下, 群众的眼睛是雪亮的.
说到新手谋生, 我看到了太多从易语言起家的开发者, 而原本他们也许会迟很多才进入英文编程的门槛.
建议你先看看对在代码中使用中文命名的质疑与回应, 假如你开发过业余项目, 相信你也碰到过无法理解自己写的的英文命名的时候. 而业余项目或者随手写的小工具恰恰是数量上最多也是门槛最低的. 在这些项目中用中文命名, 不但能节省自身精力, 而且还能因为节省的开发成本而促使更多业余项目能有更长足持久的发展, 发展成真正成气候的开源项目, 这些项目成熟后, 又可以促进企业对于中文编程/命名的信心, 从而进入商业项目. 这本身就是中文编程生态圈建立的一个最可行途径之一.
之前也说过, 如若发现我们的文章中有夸大不实成分, 请不吝赐教!
这就是这个讨论组的初衷.
呵呵, 相比起那些不择手段地反对中文编程的水文, 我只能说我们的宣传还是太保守了.
无论背景和教育水平, 对编程, 或者说让电脑完成自己想做的事这一需求是非常一致的. 而中文编程能够让更多的人更早也更容易地满足这一需求. 我认为这就是功德. 而更多人的参与, 只要是真心实意的探讨和切磋, 对中文编程都有百利而无一害.
上面应该已经说的很清楚了. 另外, 在至今的所有讨论组成员中, 我还没有发觉一位是为了名利而参与的. 说白了, 就像很多前辈们经历过的, 这条路艰辛而漫长, 直至今日也没有看到明确的曙光. 反过来说, 假如中文编程已经是明显有利可图的方向, 以现在的风险投资一窝蜂追热点的劲头, 恐怕早就吹成个大肥皂泡了.
不需要等. 现在这一秒就可以开始用中文命名进行编程. 如果你用的语言/框架不支持中文命名, 烦请告知.
引自这里:
你太低估前辈们的翻译水平了. 也太高估英语关键词和英文自然语言的接近程度了. 没有任何一个不懂编程的老外会对thread的计算机含义一目了然. 而"线程"至少包含了'线'和'程'两个含义. 其中'程'只要对"进程"了解, 就能够联系起两者. 相比thread和process, 明显是中文术语更能体现他们的关联. 另外, 你真的认为这些术语是中文编程的障碍吗? 中国人为了学编程, 可以愿意背几百几千个英文单词, 这区区数十个已经约定俗成的常用中文术语还能难倒我们吗? |
@bldght 再提醒一下, 以后像#40 (comment) 对帖子主题本身合理性的讨论的还是请到这里进行.
在 @bctnry的 #40 (comment) 之外, '总线'也是个公交线路的中文术语. |
宣扬程序语言本土化,无异于闭关锁国! |
@JerryChin 本土化等价于闭关锁国吗?那反对本土化是不是就卖国了? |
@JerryChin 存在使用母语编程的硬需求, 这里就是通过各种技术手段满足这一需求 |
@ZoomQuiet 刚拜读了前作. 对其中几点很有同感:
同感: 从人机交互角度看中文编程:'打开微信'. 个人认为确实是个很大的应用方向, 欢迎开新issue讨论. 不过语音输入也要转化为文本, 之后就是一个编译过程了. 之前尝试过设计比较简单的日常事务处理语言. |
如果指的是那篇自述文, 如有意见建议请在这里明示. 毕竟有时旁观者清. |
前文:https://zhuanlan.zhihu.com/p/48272342 《专栏一岁了-我为什么投身于普及用中文编程 下文/评论节选》
|
@Absente 我想听的是你的意见/建议. 类似的评论之前已经看到了 |
@nobodxbodon 我的观点:通过一种通用的、符合中文逻辑的programming language或programming notation,来进行编程/演示说明。在其中加入中文命名。而不是把中文编程和中文命名笼统的放在一起。 这是基于现状考虑的,因为很多人看到中文编程就觉得,啊,有时一个民科/骗钱的。 背景参考: 关于翻译,我的观点和《中文编程的迷思 类似,有用,但是现状是用处不大,甚至必要性不充分。翻译这块,所以个人能做的最简单的也只是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)
假设我已经做好了一个专门处理代码翻译的vscode插件,这时候,有一个[显示:翻译/中文]选项,里面有几个子选项/多选:1 翻译常用词 2 翻译生僻词 3 翻译关键词 4自定义/常用,而4里面,又有 4.3.1 翻译常用关键字 4.3b 常用关键词除外 4.0 自定义 假设我是个对java语法有了解的新手,这时候我选择:显示[不翻译keyword+翻译常用词+不分词翻译],那么得到的结果应该是这样子:
假设我是一个老手,但是英语比较差。想在兼容代码的同时,借助中文命名提升效率。这时候我可能会选择:翻译/改动[检查依赖+翻译所有词+启用分词翻译+不生成辅助代码],那么结果应当是:
基于上一个假设的前提,再假设我比较懒,启用了[生成辅助代码],那么结果应该是:
这个时候,完全可以把 举例就先到这里。总的来说,基于插件的代码翻译,还是要实用为主。如果做翻译插件,可以先做显示层的remap,再做批量中文命名,再做modeling output 而在具体的翻译这块,也可以部分融入拼音的元素在里面,把拼音命名或拼音缩写展开成中文 关于[生成翻译过的API文档],个人觉得可以按需翻译,这样个环节,和输出代码结构有不少交集,相当于把外部依赖都罗列清楚了 最后,关于[真正阻碍非英语用户编程的是什么]这个问题,其实是个比较复杂的问题,故不在此赘述 |
@Absente 关于代码翻译的技术细节可以另行讨论. 我在意的是, 在两个帖子(包括在你发v2帖之前我的自述文在v2的转帖讨论)中, 有数百条回复, 且不说正面建设性的回复也不少, 在负面回复中也有值得借鉴的部分, 而你挑了这条有离间色彩的专门转帖到这里让我参考, 我需要明白你看到的参考意义是什么. |
@nobodxbodon 明白你的意思了。那段话可能是有一点分裂的意思,但我的理解是,用中文的逻辑编程,和用中文写代码,确实是两个topic。而现状是,统一用中文编程的名号对外宣传,在没有说服力的项目出现之前,宣传上遇到的阻碍会越来越多,毕竟刻板印象的人还是太多了。所以我现在的策略是,编程语言的设计,先做符号化/符合中文逻辑的通用形式即可。而中文命名则无须多言,需要用多少用多少。 所以那段话主要的参考意义,需要结合那个[概念划分]的issue的语境来参考。中文命名的阻碍只有一个,就是输入法。而中文式的编程语言的阻碍,则是整个西方的CS体系。 |
除去那段话中对我的含沙射影, 我的理解是它试图把中文命名从中文编程中割裂出来. 与此相关最典型的一种言论就是, 没有成熟的中文语法的编程语言之前, 使用中文命名是无关紧要或没有意义的.
请详述什么是"用中文的逻辑编程"? 个人认为业务逻辑是程序逻辑中最重要的部分之一.
我看到的情况是, "命名只能是英文的"这一想法还非常普遍, 我的短期目标就是转变这一想法. |
@nobodxbodon 我觉得更多人的对中文命名的接受程度,取决于IDE或输入法对中文输入的友好程度。更多的人应该是认为:汉化关键词的意义是最小的,其次是翻译代码,最后是中文命名。 关于[用中文的逻辑编程]这点,先说什么是反例吧。我觉得[for in]这种语法就是用英语的逻辑去编程,而prolog则是用数学[解题/回溯]的思路去编程。关于具体什么[中文的逻辑/编程],这方面的内容我还没有准备充分,等有了足够完善的内容再补充。 关于["命名只能是英文的"这一想法还非常普遍],我认为主要是3点。1是输入法问题,这一点不经体现在编写代码的时候,同样体现在部署程序的时候,比如linux无GUI的情况下需要修改代码,这时候没有中文输入就很尴尬。 2是刻板印象,当然另一方面,很多编程语言工具确实对unicode支持不到位。3是文化帝国主义的问题 |
@Absente 如果你转帖那条评论只想说明"不少人对中文命名仍不以为然"这一事实, 请在今后类似转帖时说明清楚, 以避免不必要的误会. 如我之前所言, 在数百条评论中专挑此条拿来参考, 难免让当事人有其他联想. |
想法一致。这样能实现国际化的母语编程,甚至是个性化语言编程。 |
可能我们说的不是一个点。 打个比方,实现这种机制后,同一套源码(但一般不需要开发者直接面对),而IDE通过一套(对应或转换)机制,可以让你在你的IDE里用中文编程,我在我的IDE里用类C语言语法,另外一个人用西班牙文自然语法。 也就是说,并没有一个类似“易语言”的钦定语法(绑架了所有人,实际上目前的所有语言都是如此),每个人都可以自己定义一套符合自己习惯的语法语序,在你的IDE里,可能是形式是:循环 3000次:做点事,在我的IDE里则可能是:给我做点事=>重复:3000次 再打个比方,易语言或者其它中文编程语言,本质上是新作了一套语法,而HAXE类似于在英语汉语等世界各大语言之外做了一套世界语(并以此为中心语言做转换)。而上面说的这种这种方式,则是做了一个翻译机。 所以说,你第一段话所担心的问题其实是不存在的。 或者这样说可能更清楚了: 某天,最后只剩下(底层)源代码是同一个(但我们基本不直接面对它)。 当然这套机制实现难度肯定很高,因为涉及到语法语序的全面兼容。但我觉得比做翻译机要容易得多,因为(可能不好表达,这里只能简单说说。):用于人来交流的自然语言的形式是不可控的,和语境有关系,而社会语境是无限的;而针对编程开发所需要的语言体系,即便有语境问题,但这里的语境一定是有限和可控的。 |
@mandolin 谷歌翻译? |
未来的谷歌翻译(或者XX翻译)。 |
现在的编译器前后端设计就已经提供了定制前端的机制吧. 没看出需要额外开发的架构. |
|
@darkcmh #40 (comment) 中提到一些推广相关的非技术问题,感觉也许在这讨论更方便。技术相关的部分还请继续在那边讨论。
个人认为从自身(中文编程用户)角度出发考虑设计即可。因为设计再好的命名规范也拦不住一句”中文输入比英文麻烦“。相当大比重的反对声是为了反对而反对。
同上,尽量从自身考虑为好。任何一点语法相似性都可以被拿来说事。这种过去近二十年都不断被攻击的点上,大可以不去理会。当然,对于”摒弃原有的照搬式的类C编程语言的方式,只能在一定程度上借鉴“,个人完全赞同。 |
单纯的问问用中文的目的何在。。 |
@Quandong-Zhang |
为何多数听到中文编程的第一反应就是效率不如英文编程? - 流星暴雨的回答 - 知乎
|
源自: program-in-chinese/Java#1 (comment)
道理不辨不明. 即使是反面的意见也会有正面意义. 欢迎灌水. 将从中提取有用建议到新issue.
此后, 其他帖中的类似内容将被归整到此处(如果是新开的issue将被close, 如果是与原主题帖无关的跟帖回复将被删除).
The text was updated successfully, but these errors were encountered: