- 论坛徽章:
- 0
|
回复 55# zylthinking
就不应该叫C语言,这样太容易混淆。
M$的C++/CLI也没直接敢叫C++,差得太多了。
语言设计不是学科。比起技术更像艺术。
我是想不出来语言设计学有什么作用, 或者严谨些, 对不写编译器的或者不和开发编译器的人一起工作的人有什么作用
没用不必理会就是了,并不是谁都有空传播价值观。可以回避,但别无视。
你是可以玩的很high, 但你的贡献输出在哪里? 论坛排砖, 回答语法问题??
除了这个呢, 如果你能写编译器, 那么你可以将你思考的, 设计的语法模型体现到你的编译器中, 算是给语言进化做贡献了; 但你不会写, 而且也不是一个编译器开发团队中的语法设计人员, 那你怎么体现你的价值?
对于有兴趣的人,自然有贡献。拍砖是娱乐的形式的一种。回答语法问题倒可以算。
我不会写≠我永远不会写。
再有一点, 语言设计学是创新还是记忆现有规则呢, 背C标准朗朗上口的诸位, 可有一份自己的创新在心, 并且对其可实现性及对现有体系的影响有一定程度的胸有成竹?
都有。
再说说记忆几条标准条文, “看了几个库函数” 哪个更象 “背过了N条shell命令”
首先不管是不是, 先将背shell命令做负面典型
那么表面上记忆几条标准原文 和 看几个库函数很像, 似乎都是记忆为主, 没错; 但看库函数从来都不是做多选题为目的; 看库函数靠记忆, 但组合库函数成一个完整严密可以工作的逻辑呢, 那算什么?
看标准原文是以组合条文为目的的吗, 为什么每每引用条文时总是单独的那几条, 组合出来的也总是那几乎不变的几个方面?
要真只是死记,也没必要引用原文了,直接脱口成章不是更方便?
翻标准原文照样也不是为了做题,而是为了应用:解决各种因为语义模糊导致的行为不一致——包括一些源代码兼容性的问题。
至于会不会用,看各人造化了。
组合条文要看你怎么理解。如果只是字面上的生搬硬套那就错了,大约相当于看了几个库函数要合起来用的时候只看类型是否兼容。你是如何看出“几乎不变”的?
其实很多重申都是没办法的事情,本来应该是基本概念的东西,直接就可以拿来推理解决问题,偏偏要怕某些人不知道所以再说明一遍……哎。
|
|