木兰重生:交互环境复现,新添新手入门

2020年09月15日

上周重现了交互环境(REPL),期间用一个针对编程新手的木兰入门教程验证了基本功能。下面是教程里例程在交互中的运行效果:

注:“随机数”API 需安装草蟒库

木兰向您问好
更多信息请说'你好'
> using 随机范围数 in 随机数
> 想的 = 随机范围数(100)
> loop {
>>   猜的 = int(input("猜吧:"))
>>   if 猜的 > 想的 {
>>     println("大了")
>>   } elif 猜的 < 想的 {
>>     println("小了")
>>   } else {
>>     println("中了!")
>>     break
>>   }
>> }
猜吧:90
大了
猜吧:40
小了
猜吧:70
小了
猜吧:80
大了
猜吧:75
大了
猜吧:72
小了
猜吧:73
小了
猜吧:74
中了! 

期间发现一个木兰交互环境相对 Python 的优势,就是对粘贴代码到交互环境运行这一使用场景的支持较好,在这点上来说尤其对编程新手比较友好。详见木兰 vs. Python 之语法对用户体验的影响(一)一文。

代码统计

下面是几个主要部分的代码行数统计,格式为:上次->现在。

  • 测试
    • 测试/unittest/交互.py,交互环境相关测试:28
    • 未变
      • 木兰测试用例:1919
      • 测试/运行所有.py,检验所有木兰测试代码片段:156 -> 180
      • 测试/unittest/语法树.py,确保生成的语法树与原始版本一致:67
  • Python 总代码量(包括测试部分):2237 -> 2418
    • 环境.py,加载木兰模块:137 -> 149
    • 交互.py,交互环境(REPL):138
    • 中.py,主程序:36 -> 40
    • 未变
      • 分析器/语法分析器.py:913
      • 分析器/词法分析器.py:190
      • 分析器/语法树.py:178
      • 演示高亮.py:100
      • 分析器/语法成分.py,从语法分析器中提取出来的枚举常量:78
      • 功用/反馈信息.py:49
      • 分析器/错误.py:17

后感

之前决定暂时放下交互控制台已是五个月前,这近半年来对木兰逐步熟悉,现在再复现这部分感觉比之前轻松了不少。

但限于个人水平,对木兰的设计思路只能靠复原出的功能进行点滴参悟,肯定还有不小偏差。很希望木兰编程语言原团队的人员能够参与到项目中来,这样必然事半功倍,对设计意图进行更全面系统的复原。

展开阅读全文
0 收藏
分享
加载中
精彩评论
写代码要频繁的输入法切换?醉了
2020-09-15 20:03
3
举报
什么!?关键字都不是中文的!!! 差评😂
2020-09-15 18:27
3
举报
读代码所耗时间远远超过写代码的,更不用说不少时候起英文命名还要翻字典:
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
了解一下代码可读性,再好好回忆一下在英文命名上浪费过自己和别人多少时间。
2020-09-15 23:29
1
举报
喷子真多
2020-09-15 20:00
1
举报
加油!很棒!再接再厉!
2020-09-15 17:19
1
举报
最新评论 (26)
1.尽量做到自举,2尽量有自己的语法叔
2020-09-17 13:24
0
回复
举报
虽都有意义,但都不在本项目目标内。
2020-09-17 14:04
0
回复
举报
中英文混输对新手不好吧。新手可能觉得“如果”,“假如”,这意思不都是一样的吗,为啥程序就是不运行。
2020-09-15 21:14
0
回复
举报
真有这种反馈的话,实现起来也容易。本项目旨在重现木兰的语法和功能,有兴趣的大可在此基础上改进。
2020-09-15 23:23
0
回复
举报
写代码要频繁的输入法切换?醉了
2020-09-15 20:03
3
回复
举报
读代码所耗时间远远超过写代码的,更不用说不少时候起英文命名还要翻字典:
“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” ― Robert C. Martin, Clean Code: A Handbook of Agile Software Craftsmanship
了解一下代码可读性,再好好回忆一下在英文命名上浪费过自己和别人多少时间。
2020-09-15 23:29
1
回复
举报
主要是英文表音不表意,用英文,信息的表达效率太低。
2020-09-16 12:10
0
回复
举报
第二语言终归在表达、理解效率上都很难达到母语的程度。
2020-09-16 13:10
0
回复
举报
对,再就是数学式书写也带来大量重复劳动和无意义的命名麻烦。
2020-09-16 15:10
0
回复
举报
是指更接近自然语言的语法可以节省一些命名吗?可否举个例子呢?
2020-09-16 23:11
0
回复
举报
回复 @吴烜2020 : 应该是更接近自然语言的语法处理方式可以节省命名。人说话,会先确定一定范围,然后优先在这个范围筛选。现有语言,为了区分同类事务的,得在命名上有区别。比如,读两个文件,现有就得命名A和B,而自然语言,只用说读两个文件。
2020-09-17 12:23
0
回复
举报
回复 @dwcz : 如果是这个例子,“文件[2]”这样的数组就可以表示吧。虽然感觉自然语言会节省一些命名,但一时似乎没想到什么典型的例子。尤其现在有匿名函数和_这种类似于代词的编程语言语法,似乎不大必要的命名都可以省去了。
2020-09-17 13:08
0
回复
举报
回复 @吴烜2020 : 在现有书写模式不会有很大优势。在现有模式下,主要是提高信息表达效率。要发挥优势,必须在类似画图模式下,才可以。毕竟画图模式显示空间有限。
2020-09-17 13:33
0
回复
举报
回复 @吴烜2020 : 再就是,自然语言模式更主要是和自动代码生成配合起来,才能有更好的使用场景。像用数组来替代,还是多了一道不必要的转换。毕竟"文件"需要的信息已经提供了,只是机器不知道怎么组合。
2020-09-17 13:40
0
回复
举报
喷子真多
2020-09-15 20:00
1
回复
举报
什么!?关键字都不是中文的!!! 差评😂
2020-09-15 18:27
3
回复
举报
开源了,自己改。
2020-09-15 23:26
0
回复
举报
https://zhuanlan.zhihu.com/p/103909248
2020-09-15 18:11
0
回复
举报
所以呢?不碍着我好好研究木兰的功能和实现。要是觉得可以隔夜就写出木兰的全部功能,欢迎来取赏。
2020-09-15 23:19
0
回复
举报
加油!很棒!再接再厉!
2020-09-15 17:19
1
回复
举报
要不全中文,要不全英文,这算啥?
2020-09-15 15:51
0
回复
举报
教条无益。适合自己的最好。
那么多英文编程语言都支持非英文命名标识符,也是非英语母语的开发者共同推动的结果。看看《RFC#2457——Rust 语言选择支持非 ASCII 码标识符在 GitHub 引发的激辩(二)》
语言支持中文命名,自己偏忍着不用,是固步自封。
2020-09-15 16:01
0
回复
举报
精神和技术都是蛮厉害的,不过,我觉得这种中英文混合,以及用英语单词的思路来套中文,本身就是对初学者很不友好的。
2020-09-15 15:11
0
回复
举报
用不惯中文命名标识符的不强求。教程里的例程用中文命名对初学者理解更方便。
2020-09-15 15:18
0
回复
举报
建议吧标点符号也换成中文的()。等等😉
2020-09-15 18:30
0
回复
举报
中文标点不适合现有的编程书写方式,即不好看也不好用。我在nim上试了的。
2020-09-16 12:07
0
回复
举报
更多评论
26 评论
0 收藏
分享
返回顶部
顶部