无忧启动论坛

标题: 编程语言的探究 [打印本页]
作者: 不点    时间: 2017-8-9 21:29
标题: 编程语言的探究
从今天开始，准备搜集编程语言方面的知识，试图找出一个最理想的编程语言。这里的判断标准，当然只代表我自己，是我自己的标准。我写的东西，不一定有用，也不一定成熟。我是随便写写，就像随笔或日志。着重点是探究、学习。也许写成博客比较好，因为博客不影响别人。然而我没有博客，而且也不知道哪个博客最好。所以呢，就想在这里写了。希望不至于干扰了他人的日常生活。
作者: 20090101    时间: 2017-8-9 21:50
我也跟你学习学习
作者: vaf    时间: 2017-8-9 22:28
能听懂人语言的语言最好, 连学都不用学.
不过, 需要等待......
作者: 不点    时间: 2017-8-10 07:22
先学习 GNU Octave: https://www.gnu.org/software/octave/

先看流程控制语句。

一、if 语句

示例：

  1. if (rem (x, 2) == 0)
  2.     printf ("x is even\n");
  3. elseif (rem (x, 3) == 0)
  4.     printf ("x is odd and divisible by 3\n");
  5. else
  6.     printf ("x is odd\n");
  7. endif
复制代码

很多语言都使用 if 和 else 关键字。而在 elseif 和 endif 上，不同的语言有不同的表现。C 语言没有 elseif 和 endif。有些语言使用 elif 和 fi。

这里容易引起错误的是，把 elseif 拆开成 else 和 if。因此，我觉得 C 语言的处理方式比较干净利索。C 语言的缺点是，用花括号来结束各种控制结构，可读性不那么好。但这个缺点不太严重。



二、switch 语句

  1. switch (X)
  2.   case 1
  3.     do_something ();
  4.   case 2
  5.     do_something_else ();
  6.   otherwise
  7.     do_something_completely_different ();
  8. endswitch
复制代码

看到模仿 C 语言的痕迹了，只是把 default 关键字换成了 otherwise。各个 case 之间是互不“贯通”的，这一点不同于 C 语言。因此，它不需要 break 语句来跳出 switch 语句块。

我倾向于认可 C 语言的处理方式，case 之间可以贯通，有时候是很有用的（经常见到有人这样使用）。无条件地“取缔”这种贯通，等于是损失了功能。然而 C 语言的 break 命令是有缺陷的，它既能跳出 switch 块，也能跳出循环结构，不合理。看这样的情况：

  1. for (;;)
  2. {
  3.     switch(x)
  4.     {
  5.         case ...
  6.         //假如想在这个地方跳出 for 循环，却没办法用 break 来实现，因为 break 只是跳出 switch 块了。
  7.         case ...
  8.     }
  9. }
复制代码

因此，应该使用另外一个关键字来跳出 switch 块。

作者: 金    时间: 2017-8-10 07:37
不点 发表于 2017-8-10 07:22
先学习 GNU Octave: https://www.gnu.org/software/octave/

先看流程控制语句。

厉害了，大佬能讲下Delphi 和 C 吗。这个语言还没有接触过
作者: nttwqz    时间: 2017-8-10 09:02
个人觉得吧，没有最理想的语言，只有相对理想的语言

话说，电脑版什么时候加了个验证回答，哈哈哈哈……
作者: pcfan120    时间: 2017-8-10 09:39
严重支持 不点 大大。。。 ^_^
我也希望学点编程的知识
作者: pcfan120    时间: 2017-8-10 09:41
哦，突然发现论坛改进了。。发贴需要 验证。。希望越来越好。。
作者: 邪恶海盗    时间: 2017-8-10 12:02
其实个人认为,如果不是开发什么大的项目地话,不必纠结编程语言的问题,只要会用一种就行了...

话说我是什么都不会的...
作者: 邪恶海盗    时间: 2017-8-10 12:04
至于博客,可以考虑typecho,很轻巧的一个PHP博客程序,交流也很方便的

还可以考虑使用论坛程序来做博客,比如xiuno,反正我觉得可以...
作者: 不点    时间: 2017-8-11 07:34
前面在学习流程控制语句时，其实碰到了一个古老的话题：结构化程序设计(Structured programming)。现在就复习一下有关知识。

主要内容摘录：

1、结构化程序设计方法的起源来自对 GOTO 语句的认识和争论。

2、GOTO 语句确实有害，应当尽量避免；

3、完全避免使用 GOTO 语句也并非是个明智的方法，有些地方使用 GOTO 语句，会使程序流程更清楚、效率更高；

4、争论的焦点不应该放在是否取消 GOTO 语句上，而应该放在用什么样的程序结构上。其中最关键的是，应在以提高程序清晰性为目标的结构化方法中限制使用 GOTO 语句。

5、结构化程序设计主要强调的是程序的易读性。

6、任何程序都可由顺序、选择、循环三种基本控制结构构造。三种结构的任意组合和嵌套就构成了结构化的程序。

7、每一个结构只有一个入口和一个出口。

8、任何一个有 GOTO 的程序，可以改为完全不使用 GOTO 的程序。


注意上述第 3 条，其实是说 goto 不可以彻底消灭。换句话说，仅仅使用三种基本控制结构，并不能达到所有的程序设计目标。goto 确实可以被取代，但有时会因此而损失性能。在效率和性能不太重要的场合，可以取缔 goto 语句。

Octave 这个语言，就已经取缔了 goto。因此，Octave 是一个高级语言。那些低级、中级语言（Assembly，C ），是离不开 goto 的。毋庸置疑，低级、中级语言肯定是效率高、性能好的语言。

总结一下：在大多数情况下，可以不使用 goto。但在一些少数情况下，必须使用 goto。如果一个编程语言想“打通”、“通吃”高级语言和低级语言，那它应该包含 goto，否则它只能用作高级语言，无法兼具低级语言的功能。

记得 BASIC 语言不允许从循环体之外 goto 到循环体之内。然而 C 语言却允许这么做。C 语言的 goto 几乎允许任意的跳转。然而编程者们都会尽量避免使用 goto，因此 goto 总体使用率是很低的。但不管使用率怎么低，它也是有可能使用到的，彻底取缔不合适（如果这个语言一定要照顾中、低级的程序设计的话）。

有一个叫做 HLA（High-Level-Assembly）的语言，它就是“高级语言化”了的“低级语言”。可惜的是，它只支持 Intel 平台，不支持 ARM 平台。然而这个编程语言是开源的，因此将来有可能支持 ARM 平台。

在 HLA 中，你想用高级就用高级，想用低级就用低级，编程者的自由度空前扩大了！

作者: 不点    时间: 2017-8-12 07:08
在搜索 HLA 时，顺便发现了 IR 和 LLVM。参考：

IR is better than assembly
https://idea.popcount.org/2013-07-24-ir-is-better-than-assembly/
作者: 不点    时间: 2017-8-12 10:22
本帖最后由 不点 于 2017-8-12 18:48 编辑

关于 goto 的话题还有很多（在搜索引擎里面搜“java goto”）。Java 就是明确禁止 goto 的一个语言。goto 是 Java 的一个关键字，但却是个不能使用的关键字（这好像有点绕口）。我猜 Java 的设计者担心 C 程序员习惯地把 goto 带过来，于是就让那些含有 goto 的程序无法编译。就是说，让 goto 成为一个“能够引起编译错误”的关键字（这就不绕口了）。

Java 的这个做法，我并不认同（前面我已经提到，goto 不可以彻底取缔）。但此处不谈这个问题，而是谈谈 Java 撤销 goto 以后的一个补救思路。这里顺便说说，goto 虽然撤销了，但还得有补救的措施！这反过来印证了，goto 并非完全无用（从哲学上讲），就算是 Java 的开发者，也能隐约认识到这一点（我是否曲解了 Java 开发者的本意？但我觉得在哲学上可以这么理解或“曲解”吧）。

在循环嵌套的情形，Java 让（外层的）for 循环（能够）带上标号，在（内层）循环体内的 break（ 或 continue）语句（后跟标号）就可以跳出（或继续）外层的 for 循环。可以看出，Java 的开发者认为，goto 的用处就在这一种情形。因此，他认为没必要使用 goto（而用 break 和 continue 来简单地取代了）。我认为，goto 的应用场合，绝不只有这么狭窄的一种情形。在有些特殊的程序设计任务中，甚至需要从循环体外 goto 到循环体内！这里不展开讨论。


无论如何，“给 for 循环加上标号”这个思路有闪光点，可以借鉴。

“for 循环”可以看成一个“语句块”，因此，假如我们推广一下，让所有的语句块都可以有标号，那可能就更有用了。目前的 C 语言不能为“语句块”定义标号。C 语言的标号只代表一个“地点”，不过这个“地点”的位置（几乎）可以设置在程序中的任何地方。假如我们重新解释 C 语言的标号，让这个标号能够代表其后（紧接着的）语句块（单一语句也可以看成一个特殊的语句块）的标号，那就可以像 Java 那样来处理了。Java 的那种处理方法的实质，我认为，属于“结构化 goto”的范畴。就是说，虽然 goto 本身破坏了“结构化”，但通过对 goto 进行“规范化”，让 goto 能够纳入（用户定义的某个新的）“结构化”框架内，那就完全没问题了。

在 https://stackoverflow.com/questions/2545103/is-there-a-goto-statement-in-java
有这样一个 Java 的示例（我不确定是否符合 Java 语法，但我认为这个设计的构思很棒！）：
  1. public static void main(String [] args) {

  3.      boolean t = true;

  5.      first: {
  6.         second: {
  7.            third: {
  8.                System.out.println("Before the break");

  10.                if (t) {
  11.                   break second;
  12.                }

  14.                System.out.println("Not executed");
  15.            }

  17.            System.out.println("Not executed - end of second block");
  18.         }

  20.         System.out.println("End of third block");
  21.      }
  22. }
复制代码


上述代码说明了如何能够在 Java 中使用 goto（用 break 曲径通幽）。在上述代码中，既然 break 可以用在循环体之外，那么，continue 是否也能用在循环体之外呢？（——这是不是有点“难为情”？）因此，在这样一个例子中，如果能够使用 goto 关键字，岂不是更好？我们来分析一下上述代码中 “break second;”语句的缺陷。（程序是给人看的）人首先要查到 second 这个标号；然后，还要找到 second 块的尾部（是个花括号）。这累不累呀？还有点“变态”吧？如果允许使用 goto 的话，那么直接在尾部花括号处写上一个标号，岂不更清晰？

不过，上述示例能够为语句块设置标号，确实是一个不错的构思。我觉得，可以利用这一点，来为 C 语言的 goto“脱困”，即，对 goto 进行“结构化封装改造”。大致思路如下：

  1. my_label: //这就是下面语句块的标号。在一个具有标号的语句块里面，是可以随便使用 goto 的。
  2. {
  3.                 //这里面可以是一个很复杂的程序，但所有的 goto 都不跳出语句块之外。
  4.                 for (;;) {
  5.                                 //.........
  6.                                 if (......) goto  my_label_02;
  7.                 }
  8. my_label_01:
  9.                 for (;;) {
  10.                                 //.........
  11.                                 if (......) goto  my_label_03;
  12.                 }
  13. my_label_02:
  14.                 for (;;) {
  15.                                 //.........
  16.                                 if (......) goto  my_label_01;
  17.                 }
  18. my_label_03:
  19.                 for (;;) {
  20.                                 //.........
  21.                                 if (......) goto  my_label_02;
  22.                 }
  23.                 //上面只展示了跳出循环体的情况。其实 goto 不只是可以跳出循环体，甚至也可以从循环体外跳入循环体，就像 C 语言目前的设计那样。
  24. }
复制代码


像这样被封装了的 goto，就认为是安全的，完全不影响语句块之外的情况。上述 my_label 语句块，就相当于“用户自定义的一个新结构”了。

整体思路就是：对 goto 的使用方式，不加任何实质性的限制；所限制的，仅仅是 goto 的使用“格式”，即，必须在“允许使用 goto 的程序块”里面，才可以使用 goto。

以上仅仅是举例如何封装 goto 罢了（仅仅是个思路）。具体的封装办法可能是多种多样的。

作者: slore    时间: 2017-8-13 10:43
然而 C 语言的 break 命令是有缺陷的，它既能跳出 switch 块，也能跳出循环结构，不合理。


语法要设计简单，C语言来说，break是跳出block，不管你是while,for还是switch，统一的概念，且不跨层这是一个好的清晰的设计。

  1. for..
  2.    for..
  3.    ...
  4.    next
  5. next
复制代码


这种时候难道需要提供一个跳出内层for的语法，再提供一个跳出外层for的语法么？

for,switch嵌套N层的话，怎么办？break以外再有跳出语句的话，程序的逻辑需要慢慢仔细梳理了，
只break一层的话，谁都可以看得很容易。如果想跳出外层for，建议代码函数化。

  1. int switchblock(){
  2.    switch()
  3.   {
  4.     case x:
  5.       return 1;
  6.   }
  7.   return 0;
  8. }

  10. forblock(){

  12.   for (...){
  13.     if (switchblock()==1) {
  14.        break;
  15.     }
  16.   }
  17. }
复制代码
作者: slore    时间: 2017-8-13 11:01
3、完全避免使用 GOTO 语句也并非是个明智的方法，有些地方使用 GOTO 语句，会使程序流程更清楚、效率更高；
注意上述第 3 条，其实是说 goto 不可以彻底消灭。换句话说，仅仅使用三种基本控制结构，并不能达到所有的程序设计目标。goto 确实可以被取代，但有时会因此而损失性能。在效率和性能不太重要的场合，可以取缔 goto 语句。

Java 的这个做法，我并不认同（前面我已经提到，goto 不可以彻底取缔）。


有很多语言都是没有goto的了包括主流语言，所以说不可以彻底取缔不过是你个人的看法。

goto是某些场合，代码更清晰，比如 异常处理，这个也是目前我们唯一允许使用goto的使用场合。
更多的时候是造成代码逻辑混乱，全局变量等共享数据看起来有始无终。
“效率更高”现在是微乎及微的，函数化总是可以让代码不用goto，不过代码会多些，
效率上来说，不过多几次调用并没有什么效率影响。函数化后，反而让其他人更容易理解编写人的意图，
基本上是弊大于利的，某些场合有奇效，但是更多时候不易懂，容易埋下潜在BUG，所以不推荐。
作者: 不点    时间: 2017-8-14 00:49
谢谢以上各位关注这个话题并参与讨论。很抱歉，没能及时给您回复。

回 slore 兄，谢谢捧场，谢谢深入讨论技术话题。

我在一楼已经申明，这是博客、随笔性质的，是代表我个人的评判标准的。因为从我的哲学认识来看，世上没什么真理，所谓真理，都是自己认定的，没什么标准。

您对我的观点提出异议，这本身是瞧得起我，也是对我的尊重。那么，假如我要辩解，提出我的反驳意见，那也是对您的尊重。

我要辩解的是，goto 使用量本来就不会很多，尤其是，当已经存在三种基本控制结构以后。

在 goto 造成巨大麻烦的年代里，那时候缺少控制结构，人们大量使用 goto，这才造成问题。

在 goto 的使用频率非常低的“现代化”年代里，goto 根本就没机会造成问题。——这就是我主要反驳的理由。

请不要认为我“有意鼓励”使用 goto ——我绝对没有这个意思。我并不认为使用 goto 了就“特别好”。我也同大多数人一样，认为应该尽量避免使用 goto。

我是在为那些必须使用 goto 的场合（有这样的场合，不管它多么的稀少）找到一个“用户自定义结构”的解决办法。我这种办法，完全不排斥目前行之有效的结构化成果；我的办法是与目前的结构化方案兼容的。也许对某个人来说，他整个一生的工作都碰不上需要使用 goto 的场合。那么，这种“用户自定义结构”对他来说就“完全无用”，他完全可以当成“垃圾”扔了（不用关注、不用投入任何学习成本；只要简单地“忽视”、或“扔掉”即可）。就是说，这种“用户自定义结构”的方法或理念，并不影响一个“正常”人在“正常”情况下的任何行为，不会对任何人带来任何麻烦。但它会对某些“不正常”人所遇到的“不正常”情况，给出解决方案。

我同意您对 goto 使用率“低”的评价。我觉得 goto 可能也就主要用在与机器指令打交道的场合了。使用率很低，是相对于那些不与机器指令打交道的场合。那些需要与机器指令打交道的场合，可能就有比较高的几率使用 goto 了。在特殊的情况下，当代码需要优化时，说不定需要节约几个字节，或禁止使用函数，禁止子程序调用（少压入一个堆栈，少执行一条指令，少浪费一点时间），等等。此时，也许最优化的方法就是使用 goto 了。像前面提到的 HLA 这个语言，就是可以采用高级结构来编写汇编语言的一种语言。我们作为一个人，来评价某个东西有用或无用、重要或不重要，都是站在自己的立场上，是自己经验的一种体现而已，因此，不能取代别人的感受和意见。

在讨论技术时，由于认识不同，侧重点不同，在有时候、有些人，可能会觉得某个话题的讨论是“吹毛求疵”的、或“高射炮打蚊子”（没必要的），等等。认识不同、立场不同，结论就可能相去甚远。因此之故，每个人都掌握着自己的真理。那真理，其实就是他自己经验的总结。这是正常现象，也是普遍现象。

我接受您的意见。从您的意见中，我看到有关 goto 的问题不那么紧要。我们所遇到的绝大多数情况，都不是“性能攸关”的。人越来越浪费了，一个人浪费的资源是很可观的（比如人消耗的水量就大得很）。所以，人越来越不注重性能的优化了，而是越来越注重一个程序对人的可读性、友好性的问题了。于是 goto 这个问题好像越来越没什么人去关注了。既然如此，那么接下来我们就换个话题，不再讨论 goto 及其相关问题了。其实，通过以上的讨论，我觉得问题也都已经摆明了，因而也就没什么可讨论的了。

谢谢 slore兄。也再次一并谢谢各位，抱歉没能及时逐一回复。


作者: 不点    时间: 2017-8-14 01:57
这几天通过搜索，发现了一个名叫 ROOT 的强大团队：

https://root.cern.ch/

这个团队开发了（曾经）强大的 CINT 语言，现在转向了 Cling 语言——这俩都是 C/C++ 语言的解释器，可用于交互式执行，也可用作脚本。

另外，LLVM 和 IR 的庞大架构也都是这个团队开发出来的。他们开发的 Clang 编译器，可以作为 gcc 的一个替代品。

值得一提的是，ROOT 所开发的产品都是开源的：

https://root.cern.ch/license

我所关注的 Cling（当然也是开源的），在这里：

https://root.cern.ch/cling

在下载页，我幸运地看到了为 ARM64 的 Linux 所编译的版本，下载并解压后就能直接在 ARM64 的 Ubuntu 下使用了（无需安装）。

目前的 Cling 比起另一个闭源的 Ch 解释器来说，还有一些差距；但我感觉，Cling 赶超 Ch，只是时间问题。

顺便说，Ch 的官网在这里： https://www.softintegration.com/





作者: 不点    时间: 2017-8-16 06:44
本帖最后由 不点 于 2017-8-16 21:06 编辑

今天在 ARM ubuntu 下成功编译了 Cling，自己祝贺一下。编译过程不太顺利，记录下来，是怕以后再遇到问题时，忘了是如何解决的。

按照 Cling 官方 https://root.cern.ch/cling-build-instructions 给出的脚本 https://raw.github.com/karies/cling-all-in-one/master/clone.sh 进行自动下载和编译。编译过程中出了很多 gcc internal error，并提示向 gcc 开发者报告 bug。我一开始以为是 cling 的代码有错，就丧失了信心。后来仔细看出错的红字提示内容，是说 gcc 的“内部错误”。这就明白，不是 Cling 代码有错，而是 gcc 执行过程出错。通过研究 clone.sh 了解到，在执行 cd obj 命令进入 obj 目录之后，make -j6 命令出错。我试试反复执行 make -j6 （这里的 6 是 CPU 核心 core 的个数，我的 RK3399 是六核的），每次出错信息都不一样，而且前面编译未通过的步骤，再次编译就可能顺利通过了。经过几个小时反复执行 make -j6 命令，终于全部编译通过。现在想想，gcc 时常出错的原因，很可能是 CPU 发热造成的。我的 CPU 没有风扇。

在顺利执行 make -j6 之后，只剩下安装的步骤了：make -j6 install。这不需要 root 用户的权限，它会把 Cling 安装在我自己的 inst 目录下。

以下是 gcc 出错信息片段：

［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o
［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/ObjectFilePCHContainerOperations.cpp.o
［62%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/SanitizerMetadata.cpp.o
［66%］ Built target clangStaticAnalyzerCheckers
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/SwiftCallingConv.cpp.o
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/TargetInfo.cpp.o
［66%］ Building CXX object tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/VarBypassDetector.cpp.o
c++: internal compiler error: 已杀死 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
c++: internal compiler error: 已杀死 (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-5/README.Bugs> for instructions.
tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/build.make:1190: recipe for target 'tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o' failed
tools/clang/lib/Sema/CMakeFiles/clangSema.dir/build.make:566: recipe for target 'tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaDeclAttr.cpp.o' failed
make［2］: *** ［tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/MicrosoftCXXABI.cpp.o］ Error 4
make［2］: *** ［tools/clang/lib/Sema/CMakeFiles/clangSema.dir/SemaDeclAttr.cpp.o］ Error 4
make［2］: *** 正在等待未完成的任务....
CMakeFiles/Makefile2:17360: recipe for target 'tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all' failed
make［1］: *** ［tools/clang/lib/Sema/CMakeFiles/clangSema.dir/all］ Error 2
make［1］: *** 正在等待未完成的任务....
[ 66%］ Built target sanstats
CMakeFiles/Makefile2:17453: recipe for target 'tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/all' failed
make［1］: *** ［tools/clang/lib/CodeGen/CMakeFiles/clangCodeGen.dir/all］ Error 2
Makefile:149: recipe for target 'all' failed
make: *** ［all］ Error 2
firefly@firefly:~/obj$


以下是 gcc 最后编译成功时的信息：


［100%］ Built target libclang
Scanning dependencies of target c-index-test
Scanning dependencies of target c-arcmt-test
［100%］ Building C object tools/clang/tools/c-arcmt-test/CMakeFiles/c-arcmt-test.dir/c-arcmt-test.c.o
［100%］ Building C object tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/c-index-test.c.o
［100%］ Building CXX object tools/clang/tools/c-index-test/CMakeFiles/c-index-test.dir/core_main.cpp.o
［100%］ Linking CXX executable ../../../../bin/c-arcmt-test
［100%］ Built target c-arcmt-test
［100%］ Linking CXX executable ../../../../bin/c-index-test
［100%］ Built target c-index-test
firefly@firefly:~/obj$


作者: hs6688    时间: 2017-8-16 07:14
感谢经验之谈
作者: 音乐与电脑    时间: 2017-8-16 11:10
新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？
作者: 音乐与电脑    时间: 2017-8-16 11:10
新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？
作者: 音乐与电脑    时间: 2017-8-16 11:10
新人表示支持。可能cpu发热严重导致程序编译不过，居然还有这种操作？楼主为什么在用arm的cpu呢？那么，楼主你认为c#，java与php怎么样？我认为c#最好，无论是代码书写难度，代码可读性，抒写效率，优化，跨平台能力，执行效率还是debug效率。有支持intel的，有没有支持amd，via与ibm的呢？支持mips与alpha的又是什么呢？
作者: 不点    时间: 2017-8-16 11:24
感谢楼上高人给以指点。本人腐朽没落，没接触过太多的编程语言。像 C#，java，php，python，ruby 等，我都仅限于知道其名称而已，基本都不曾接触过。IBM、VIA、MIPS、ALPHA 也都没机会接触。期待以后能有时间多接触、多学习。
作者: gnuxwy    时间: 2017-8-17 01:36
很喜看不点大师的贴子，总氏能分享长智者的体验，获得各种收获。
屮就只懂得一点点c和cjj，还在初步学习当中，希望以后水平高了，也能象大师一样做出优秀的产品。
作者: 音乐与电脑    时间: 2017-8-17 13:31
楼主谦虚了 我可不是高人
作者: linpinger    时间: 2017-8-18 16:57
本帖最后由 linpinger 于 2017-8-18 17:01 编辑

大大，可以再 github上写一个静态博客，会一点简单的html语言就行，不会也可以用工具来做网页，使用git来推送，还可以同步推送到 git.oschina.net 上，我就是这么做的，http://linpinger.github.io/?s=wuyou                 http://linpinger.oschina.io  后面这个链接不能直接点开，要复制粘贴，应该是对来源做了限制
作者: 不点    时间: 2017-8-18 21:16
linpinger 发表于 2017-8-18 16:57
大大，可以再 github上写一个静态博客，会一点简单的html语言就行，不会也可以用工具来做网页，使用git来推 ...

年轻的时候，经常为争取自由而斗争。现在已经没有那种活力了。不仅不去争取，而且白送给我自由，我都可能不要（我驾驭不了那种自由，宁可不要；正如许多人驾驭不了 Linux，宁可不要 Linux）。折腾自己的博客？我还真折腾不了，不是年轻人的那种心态了，没有年轻人的那种“冲劲”了（向前冲的冲，一声，不是当“怼人”讲的那个 chong4），没有年轻人的那种“朝气蓬勃”了。
作者: 不点    时间: 2017-8-18 21:35
Cling 旨在提供一款高性能的 C++ REPL
作者 Sergio De Simone，译者 谢丽  发布于 2015年5月25日 http://www.infoq.com/cn/news/2015/05/cling-cpp-interpreter

Cling 是一款交互式 C++ 解释器，以 LLVM 和 Clang 为基础构建，其目标是通过超越编码-编译-运行-调试这个惯常的 C++ 工作流程提供生产力的飞跃。

Cling 提供了一个读取-求值-输出循环（REPL），类似常见的 Unix shell，并支持 Emacs 绑定。使用 Cling 可以测试 C++ 代码片段，而不需要创建文件、包含头文件等等。使用 REPL 的主要好处是可以在极短的时间内测试一个想法，而不需要等待构建系统编译代码。REPL 在学习一门语言时也非常有用，因为它让试用语言特性变得更简单。

ROOT 是 Cern 的数据分析框架，Cling 即是由该框架背后的团队开发完成，作为现有的命令行 C/C++ 解释器 CINT 的一个替代方案。目前，在粒子物理学领域中，许多 实验 中都用到了 ROOT，包括大型“强子对撞器（Large Hadron Collider）”。

Cling 可以解析 Clang 所能解析的一切内容，并且还支持一些 CINT 特有的 C++ 扩展。ROOT 开发团队 列举 了 Cling 提供的主要好处，其中包括使用生产级解析器、JIT 允许不使用封装器直接进行库调用、使用独立的解析器和执行引擎。

Cling 在 GitHub 上开源。用户既可以使用 每日构建的二进制包 进行安装，也可以 从源代码构建。官方的 一体化构建脚本 支持基于 Unix 的系统，而 Windows 上的手动构建过程可以借助 CMake 实现。此外，Gallagher Pryor 介绍 了针对 ARM 平台构建 Cling 的步骤，这比针对 x86 平台进行构建要复杂得多，因为开发团队没有在他们的构建脚本中直接提供这种支持选项。

查看英文原文：Cling Aims to Provide a High-performance C++ REPL

正如前面帖子所说，现在在 ARM 平台编译 Cling 已经很简单了，全自动完成，不需要人工介入（cpu 发热导致 gcc 被 kill 掉，这不是 Cling 的错）。

作者: 不点    时间: 2017-8-20 01:21
Cling 编译成功后，发现 root 比 cling 更强大一些（两者都是 root 团队开发的）。于是就尝试编译 root。编译 root 稍稍费了一些周折。在 configure 和 编译过程中，有出错提示，说缺少某某软件和某某 lib 库，于是就安装相应的软件和库。有一个比较棘手的问题，需要记录下来，免得以后想不起来是怎么解决的了。

在编译 TreePlayer 时，总是提示缺少 MultiProc 库。就是说，连接参数 -lMultiProc 失败。等价地说，就是找不到 libMultiProc.so 文件。我怀疑根本就不需要这个文件，于是，我随便把 lib 目录下的另外一个文件（只要是合法的 .so 格式即可） cp 成 libMultiProc.so，果然编译通过了！等全部编译完成后，发现 lib 里面的 libMultiProc.so 也更新了（文件大小变了，不是我随便拷贝的那个 .so 的大小了）！这说明，在编译 TreePlayer 时，根本就不需要  libMultiProc.so ，而这个 libMultiProc.so 是在后续编译过程中生成的。

无论如何，费了一天的时间，能够在 ARM Linux 下把 ROOT 编译成功，也是一大收获，自己觉得很不容易，因而很高兴，自娱自乐，庆祝一下。

作者: 不点    时间: 2017-8-20 02:03
root 果然比 cling 更好一点。看这个

  1. firefly@firefly:~/root-6.10.04$ root
  2.    ------------------------------------------------------------
  3.   | Welcome to ROOT 6.10/04                http://root.cern.ch |
  4.   |                               (c) 1995-2017, The ROOT Team |
  5.   | Built for linuxarm64                                       |
  6.   | From tag v6-10-04, 28 July 2017                            |
  7.   | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
  8.    ------------------------------------------------------------

  10. root [0] cout << "jhjkhjk" << endl
  11. jhjkhjk
  12. (std::basic_ostream<char, std::char_traits<char> >::__ostream_type &) @0x7f8a126ac8
  13. root [1]
复制代码


就是说，cout 在 ROOT 下执行成功。然而 cout 在 cling 下却不行，即使加上 -std=c++11 参数也不行：

  1. firefly@firefly:~$ cling -std=c++11

  3. ****************** CLING ******************
  4. * Type C++ code and press enter to run it *
  5. *             Type .q to exit             *
  6. *******************************************
  7. [cling]$ cout << "uyhhuiyui" << endl
  8. input_line_3:2:2: error: use of undeclared identifier 'cout'
  9. cout << "uyhhuiyui" << endl
  10. ^
  11. input_line_3:2:25: error: use of undeclared identifier 'endl'
  12. cout << "uyhhuiyui" << endl
  13.                         ^
  14. [cling]$
复制代码


作者: 不点    时间: 2017-8-20 12:44
谢谢前面各位高人的支持、捧场。

今天，来点“逆向思维”，用 Ch 用户手册中的例子，来检验 ROOT 的执行结果。（注意 Ch 闭源，ROOT 开源——两者不是一家的哟！）

Ch 的用户手册是 pdf 格式：

https://www.softintegration.com/download/software/release/docs/cn/chide.pdf

以下就是操作过程：

  1. firefly@firefly:~$ root    开始进入 root 环境
  2.    ------------------------------------------------------------
  3.   | Welcome to ROOT 6.10/04                http://root.cern.ch |
  4.   |                               (c) 1995-2017, The ROOT Team |
  5.   | Built for linuxarm64                                       |
  6.   | From tag v6-10-04, 28 July 2017                            |
  7.   | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q' |
  8.    ------------------------------------------------------------

  10. root [0] 1+3*2          在提示符下敲入算术表达式，会立即显示结果。
  11. (int) 7
  12. root [1] int i              定义变量，也会显示变量的初始值（默认值）。
  13. (int) 0
  14. root [2] sizeof(int)                显示 int 的宽度是 4 字节。
  15. (unsigned long) 4
  16. root [3] i=30              赋值，也显示结果。
  17. (int) 30
  18. root [4] printf("%x", i)        打印 i 的十六进制值，正确
  19. 1e(int) 2
  20. root [5] printf("%b", i)        企图打印 i 的二进制值，ROOT 不支持 %b 指示符。Ch 支持 %b 指示符。
  21. ROOT_prompt_5:1:10: warning: invalid conversion specifier 'b' [-Wformat-invalid-specifier]
  22. printf("%b", i)
  23.         ~^
  24. %b(int) 2
  25. root [6] i = 0b11110             用二进制格式给 i 赋值，成功，说明二进制常量是支持的。
  26. (int) 30
  27. root [7] i = 0x1E                     用十六进制常量，也成功。
  28. (int) 30
  29. root [8] i=-2                            试试负数？当然不会有问题。
  30. (int) -2
  31. root [9] float f = 10              定义浮点数，成功。
  32. (float) 10.00000f
  33. root [10] 2*f                            浮点数计算，也没问题。
  34. (float) 20.00000f
  35. root [11] double d = 10        定义双精度变量
  36. (double) 10.000000
  37. root [12] d
  38. (double) 10.000000                    都正常
  39. root [13] int i=10, *p             重新定义 i 变量，不行；同时，由于出错了，因此指针 p 的定义也无效。
  40. ROOT_prompt_13:1:5: error: redefinition of 'i'
  41. int i=10, *p
  42.     ^
  43. ROOT_prompt_1:1:5: note: previous definition is here
  44. int i
  45.     ^
  46. root [14] int *p                      因此指针 p 需要重新定义，这次成功了。p 的初值是“空指针”。
  47. (int *) nullptr
  48. root [15] &i                             显示变量 i 的地址值。
  49. (int *) 0x7fb621c020
  50. root [16] p  = &i                     把 i 的地址赋给 p，成功。
  51. (int *) 0x7fb621c020
  52. root [17] *p                             显示 p 所指向的值，即 i 的值，正确
  53. (int) -2
  54. root [18] *p = 20                    让 p 所指向的值等于 20，成功
  55. (int) 20
  56. root [19] i                                 此时 i 的值也是 20 了，没问题。
  57. (int) 20
  58. root [20] int a[5] = {10,20,30,40,50}, *p        此语句重新定义了 p，失败。
  59. ROOT_prompt_20:1:31: error: redefinition of 'p'
  60. int a[5] = {10,20,30,40,50}, *p
  61.                               ^
  62. ROOT_prompt_14:1:6: note: previous definition is here
  63. int *p
  64.      ^
  65. root [21] int a[5] = {10,20,30,40,50}    失败后，需要此语句来定义数组 a。成功。
  66. (int [5]) { 10, 20, 30, 40, 50 }
  67. root [22] a                                                      这句显示 a 数组的内容，成功。
  68. (int [5]) { 10, 20, 30, 40, 50 }
  69. root [23] &a                                                   这句显示 a 的地址，也没问题。
  70. (int (*)[5]) 0x7fb621c038
  71. root [24] &a[0]                                              这句显示 a[0] 的地址，结果与 a 的地址相同，是正确的。
  72. (int *) 0x7fb621c038
  73. root [25] a[1]                                                 显示 a[1] 的值，正确。
  74. (int) 20
  75. root [26] *(a+1)                                             换一种方式来显示 a[1] 的值。
  76. (int) 20
  77. root [27] p = a+1
  78. (int *) 0x7fb621c03c
  79. root [28] *p                                                     再换一种方式。
  80. (int) 20
  81. root [29] p[0]                                                  再换一种，都正确。
  82. (int) 20
  83. root [30] a[-1]                                                 试试数组下标越界，有警告，但仍然显示结果（=127）。
  84. ROOT_prompt_30:1:1: warning: array index -1 is before the beginning of the array [-Warray-bounds]
  85. a[-1]
  86. ^ ~~
  87. ROOT_prompt_21:1:1: note: array 'a' declared here
  88. int a[5] = {10,20,30,40,50}
  89. ^
  90. (int) 127
  91. root [31] a[5]                                                   试试数组下标越界，有警告，但仍然显示结果（=0）。
  92. ROOT_prompt_31:1:1: warning: array index 5 is past the end of the array (which contains 5 elements)
  93.       [-Warray-bounds]
  94. a[5]
  95. ^ ~
  96. ROOT_prompt_21:1:1: note: array 'a' declared here
  97. int a[5] = {10,20,30,40,50}
  98. ^
  99. (int) 0
  100. root [32] char s[5]                                         定义字符数组。
  101. (char [5]) "\0\0\0"
  102. root [33] strcpy(s,"abc")                            成功写入字符串。
  103. (char *) "abc"
  104. root [34] s
  105. (char [5]) "abc"
  106. root [35] strcpy(s, "ABCDE")                    试试写入越界字符串——竟然没有警告，不安全！
  107. (char *) "ABCDE"
  108. root [36] s
  109. (char [5]) "ABCDE"
  110. root [37] struct tag {int i; double d;} s                  重新定义了 s，失败。
  111. ROOT_prompt_37:1:31: error: redefinition of 's' with a different type: 'struct tag' vs 'char [5]'
  112. struct tag {int i; double d;} s
  113.                               ^
  114. ROOT_prompt_32:1:6: note: previous definition is here
  115. char s[5]
  116.      ^
  117. root [38] struct tag {int i; double d;} ss                 换成 ss，成功。
  118. (struct tag &) @0x7fb621c058
  119. root [39] ss.i = 20                                                            显示结构成员的值，没问题。
  120. (int) 20
  121. root [40] ss
  122. (struct tag &) @0x7fb621c058
  123. root [41] ss.i
  124. (int) 20
  125. root [42] ss.d
  126. (double) 0.000000
  127. root [43] sizeof(ss)                                                       显示结构的宽度，占用 16 字节。
  128. (unsigned long) 16
  129. root [44] srand(time(NULL))                                    设置随机数种子，成功。
  130. root [45] rand()                                                               产生随机数，成功。
  131. (int) 282375281
  132. root [46] rand()                                                               再产生一个，果然是另一个不同的数。
  133. (int) 837167582
  134. root [47] double add(double a, double b) {double c; c=a+b+sin(1.5); return c;}    定义函数，成功
  135. root [48] double c
  136. (double) 0.000000
  137. root [49] c = add(10.0,20)                                         验证计算结果，是对的。
  138. (double) 30.997495
  139. root [50] cin >> i                                                           要求从键盘输入数值给 i 变量。
  140. 10                                                                                        这个 10 是敲入的，成功赋值给变量 i 了。
  141. (std::basic_istream<char, std::char_traits<char> >::__istream_type &) @0x7fb61f4e30
  142. root [51] cout << i                                                        显示 i 的值，正确。
  143. 10(std::basic_ostream<char, std::char_traits<char> >::__ostream_type &) @0x7fb61f4ac8
  144. root [52] class tagc {private: int m_i; public: void set(int); int get(int &);}        定义一个类
  145. root [53] void tagc::set(int i) {m_i = 2*i;}                               定义成员函数 set。
  146. root [54] int tagc::get(int &i) {i++; return m_i;}                   定义成员函数 get。
  147. root [55] tagc c                                                                          重新定义变量 c，失败
  148. ROOT_prompt_55:1:6: error: redefinition of 'c' with a different type: 'tagc' vs 'double'
  149. tagc c
  150.      ^
  151. ROOT_prompt_48:1:8: note: previous definition is here
  152. double c
  153.        ^
  154. root [56] tagc cc                                                     改成 cc，成功。
  155. (tagc &) @0x7fb621c070
  156. root [57] cc.set(20)                                               调用 cc 的成员函数 set。
  157. root [58] cc.get(i)                                                  调用 cc 的成员函数 get。结果正确。
  158. (int) 40
  159. root [59] i                                                                  显示 i 的值。正确。
  160. (int) 11
  161. root [60] sizeof(tagc)                                          类变量本身占用 4 字节的宽度。
  162. (unsigned long) 4
  163. root [61] .! pwd                                   ROOT 不具有 shell 的功能，只能用这种方式调用 sh 来间接使用 shell 命令。
  164. /home/firefly
  165. root [62] .! if [ 1 = 0 ]; then echo bad; else echo good; fi                 验证 shell 的条件语句能够正确执行。
  166. good
  167. root [63] .! if [ 1 = 1 ]; then echo good; else echo bad; fi                 验证 shell 的条件语句能够正确执行。
  168. good
  169. root [64] .q                                                       测试完毕，退出 ROOT 环境，回到 shell 提示符。
  170. firefly@firefly:~$
复制代码

作者: 不点    时间: 2017-8-24 00:44
今天学习一下 Ch 语言对于 Shell 里面 here document 的处理思路。在 Ch 语言的教程里面，有这样的一段话：

The following shell commands in Bourne Shell sh

  1.     #!/bin/sh
  2.     command argument << EOF
  3.       input from the console command line
  4.       abcd
  5.     EOF
复制代码

can be handled in Ch as follows:

  1.     #!/bin/ch
  2.     #include <stdio.h>
  3.     FILE *fp;
  4.     string_t command_args="input from the console command line\nabcd";
  5.     fp = popen("command", "w");
  6.     fwrite(command_args, strlen(command_args), sizeof(char), fp);
  7.     pclose(fp);
复制代码

起初，我觉得 Ch 的处理方式太复杂，难以接受。但后来，我觉得 Shell 里面的 here document，有点“添乱”的感觉，就是说，值得推敲，并不一定是个很好的设计。

首先，here document 只能处理文本，不能处理二进制数据。其次，here document 结尾的回车符，要不要呢？假如不想要，直接在 abcd 后面（同一行）跟着 EOF，这是不行的。所以这个回车符必须有，因而用户无法达到“不要结尾的回车符”的目的。第三，如果文本本身正好有一行是 EOF，那就提前结束了——如果这个程序代码是在脚本中，那么后续的多余文本行，都被错误地识别为 shell 命令，那有可能带来某些隐患。

总结一下，here document 看似方便快捷，其实陷阱很多，并不是一个完美的设计。

经过上述思考以后，我觉得 Ch 的处理方式也是可以接受的了。我在 Cling 中成功验证了 Ch 的上述代码（的思路），只增加了一行 #include <string.h> 的代码，并稍微改动了其他几处代码：

  1.     #include <string.h>
  2.     #include <stdio.h>
  3.     FILE *fp;
  4.     char command_args[]="input from the console command line\nabcd\n";
  5.     fp = popen("cat", "w");
  6.     fwrite(command_args, strlen(command_args), sizeof(char), fp);
  7.     pclose(fp);
复制代码

执行的效果等同于 shell 中的如下代码：

  1.     #!/bin/sh
  2.     cat << EOF
  3.       input from the console command line
  4.       abcd
  5.     EOF
复制代码


今天学到 Ch 的一些很有启发性的思想方法，比较满意。


作者: 不点    时间: 2017-8-29 11:24
这个主题是讨论编程语言的。汇编语言（等价的机器指令的设计），也属于编程语言。

今天就记录一下最近在 grub4dos 最新改动的代码中所暴露出来的 “CPU 指令设计” 方面的问题。

  1.          subl        %es:(%di), %eax
  2.          sbbl        %es:4(%di), %edx        /* EDX:EAX=new length */
  3.          jb        5f                        /* start_address is below the base */
  4. +        ja        7f
  5. +        /* now EDX=0 */
  6. +        testl        %eax, %eax                /* EAX also be zero? ZF holds it! */
  7. +        jne 7f
  8. +        /* Change memory address type from 1 (usable) to 2 (reserved). Note
  9. +         * that original value is long integer of 1 (all higher 3 bytes = 0).
  10. +         * So only the lowest byte needs to be incremented. */
  11. +        incb        %es:16(%di)                /* memory address type */
  12. +        jmp        5f
  13. +7:
  14.          subl        %es:8(%di), %eax
  15.          sbbl        %es:12(%di), %edx        /* EDX:EAX=difference */
  16.          jnb        5f                        /* new length is too big */
复制代码

在 32 位 CPU 中，要处理 64 位的整数，就要把 64 位整数切割成两个 32 位的整数来处理。比如说上述的 64 位减法的处理：

SUB   ..., EAX
SBB   ..., EDX

第一条指令，处理低 32 位部分，SUB 指令处理的结果，会在 Flags 状态标志中有所反映。此处比较重要的是是否有借位（CF），以及结果是否为 0（ZF）。

第二条指令，处理高 32 位部分。SBB 指令能够利用上一条指令的 CF 标志，来实施本次的减法。计算的结果，当然是正确的了。

而这里暴露出来的问题，却在于有关 ZF 设置的一个细节。目前 ZF 的设置，完全是看运算结果，而这是 “不方便” 的。我们看第二条 SBB 指令，假如它的运算结果是 0，于是，ZF 也就为 True （=1）了。而这个 ZF=1 的判断，对于程序员想要了解的整个 64 位整数结果是否为 0，是 “不舒服” 的，因为它只告诉了高 32 位为 0，还得再花费两条指令判断低 32 位是否为 0 才行（浪费指令代码的空间，也浪费执行时间）。

假如 SBB 指令能改造成利用前一条指令的 ZF 结果，那就 “顺畅” 了。具体改造思路如下：

当 ZF=0 （即前面的指令没有产生 0 的结果）时，本次 SBB 依旧采用 ZF=0（即，不更新 ZF 为本次执行的结果）。（理解：只要低位部分不为 0，整个 64 位整数肯定也就不为 0 了）

当 ZF=1 （即前面的指令运算结果已经是 0）时，本次 SBB 更新 ZF（即，根据本次运算结果，设置 ZF）。（理解：低位已经是 0，那么高位是否为 0 就表明整个 64 为整数是否为 0 了）。

如此一来，SUB ... ; SBB ...; 这两条指令执行以后，ZF 的值就能代表 64 位值是否为 0 了，无需再费劲去重复判断低 32 位的情况了。

同理，“是否大于”、“是否小于” 的问题，也可以进行类似的改造。

128 位，256 位，…… 直至 “无限大” 整数，都可以进行类似的处理。rep 前缀可以重复进行字符串的处理，进一步也可以设计，让 rep 前缀应用于 “重复处理无限大的整数的算术运算”。

作者: 不点    时间: 2017-9-3 09:48
本帖最后由 不点 于 2017-9-3 09:51 编辑

今天学了这个：

Cling – The New Interactive Interpreter for ROOT 6
http://inspirehep.net/record/1214956/files/jpconf12_396_052071.pdf

有很多背景知识介绍，包括疑难问题的处理，很有深度。留个脚印，以便下次还能找到。
作者: 2011grassll    时间: 2017-9-6 11:00
不知道不点大大有没有关注过go语言？我觉得算是最实用最好用的了，编译型的，
官方称是更好的C，实际上也继承了C，也确实可以无缝对接C程序,golang代码里就可以直接嵌进C代码。
golang自带map,slice,支持并行,gc,官方的标准库/非标准库涵盖了许多常用场景，桌面、网络、后台程序写起来都非常方便，部署也非常方便。
在方便性上比C好太多了，接近动态语言python,而在性能和部署方面又远强于python等.
作者: 不点    时间: 2017-9-6 11:08
本帖最后由 不点 于 2017-9-6 11:39 编辑
2011grassll 发表于 2017-9-6 11:00
不知道不点大大有没有关注过go语言？我觉得算是最实用最好用的了，编译型的，
官方称是更好的C，实际上也 ...


感谢指引。我找到了这里：https://golang.org/

Go is an open source programming language that makes it easy to build simple, reliable, and efficient software.

我会学习一下的。



从这里 https://golang.org/doc/faq 快速了解了一下，但很遗憾，go 没有吸引住我。可能我目前的水平比较低，还不足以让 go 来吸引住我吧。也许以后会有缘分，说不定。



作者: yxing365    时间: 2017-9-8 15:11
怎么没人提起pascal语言，这是一种国际计算机编程奥赛里面用的一种语言，结构严谨。在数学运算及围棋等方面比较强
作者: 不点    时间: 2017-9-8 23:10
发现 cling 也支持 cout，记录一下，如下：

  2. [cling]$ #include <iostream>
  3. [cling]$ using namespace std;
  4. [cling]$ cout << 0 << endl
  5. 0
  6. (std::basic_ostream<char, std::char_traits<char> >::__ostream_type &) @0x7f7cd25ac8
  7. [cling]$
复制代码
作者: gnuxwy    时间: 2017-9-10 13:06
不点老大谈到cpu支持的指令设计问题。屮觉得这可能氏个硬件实现复杂度的问题。
软件和硬件在某种程度上有一定互代性。
比如乘法指令的实现，可以用硬件实现乘法，也可以只用加法噐，然后用软件完成乘法工作。

浮点运算也氏如此，早期的8086好像就没有浮点处理的协处理噐，浮点运算必须用整数模拟运算。
似乎arm体系的cpu很多都氏没有浮点计算硬件的。这符合arm的cpu设计时常用指令低功耗的需求。

大师说的判64位归零问题，屮想有能力设计和制造cpu的公司那几个大公司的硬件工程师，不可能不知道
如果具有相应的判零直接指令可以让软件编程时更方便，但权衡了硬件实现复杂度和经济性后有意不实现的。

此外屮觉得go语言好像和c++语言的设计目标氏一致的？难道它的目标就氏取代语言特性太复杂的c++？


作者: 2011grassll    时间: 2017-9-10 20:28
本帖最后由 2011grassll 于 2017-9-10 20:38 编辑
gnuxwy 发表于 2017-9-10 13:06
不点老大谈到cpu支持的指令设计问题。屮觉得这可能氏个硬件实现复杂度的问题。
软件和硬件在某种程度上有 ...


确实，go语言的设计者就是因为不满意c++不够简洁，特性太多，编译太慢，团队开发大型软件很烦，才有了go。不谈高深的语言设计，我也不懂，光是其简洁的语法，我觉得写起来就很舒服
作者: gnuxwy    时间: 2017-9-13 00:06
语法简洁只氏评判语言的一个方面。若论简洁，脚本语言更简洁，一行脚本超过万行c程序。
程序设计语言很多，各种语言都有自已的适用领域。

有生命力的语言或开发工具，肯定要有某种重量级的应用程序采用它编程，才有说服力。
比如说linux内核以及其它操作系统内核，用c语言写成；GCC编译噐集，用cjj写成；
gtk有gnome桌面生态，qt有kde桌面生态；

这些都氏重量级的应用程序或环境，能开发它们的工具、语言、类库当然值得信赖和学习。
go语言怎么也得等它有重量级的应用使用它做开发时，程序员才能更有选择它的理由。


作者: 不点    时间: 2017-9-13 06:57
有各位高手捧场交流，真是荣幸。看了各位高论，也谈点自己的浅见。

C、C++ 的语法形式，太过于复杂。语法分析器的负担很重。这肯定算是缺点。Basic 语言最简单。我最早学习的那种 Basic，没有循环语句，只有 if 语句。那时候，大量使用 goto 语句。Basic 语言的赋值语句需要有 let 关键字（后来，let 可以省略，但我觉得糟糕了，因为有了 let 会更清晰一些）。后来的 basic 有了各种控制结构。子程序调用，需要 call 命令。子程序声明，需要 SUB 关键字。有了这些规范，程序才显得井井有序。

C、C++ 的语法太自由了，这给语法分析器带来了巨大负担。从 C、C++ 用户的角度来看，当然很自由、很舒服。所以，优点可能也是缺点，缺点也可能是优点。

目前世上有多少种编程语言？是几千？还是几万？可能没人知道准确的数目。但是，有些东西却是可以说清楚的，那就是“历史”。历史上首先有机器语言，然后有更人性化的汇编助记符（assembly），好像紧接着就是 C 语言了吧？我不知道是谁设计了 C 语言，但我很佩服此人，我觉得他很伟大。C 语言就像“世界语”一样，到处通行无阻，任何平台都支持 C 语言。别的语言都可以没有，只要有汇编语言和 C 语言，世界照样运转。哦，不要误会，我的意思是说，汇编语言和 C 语言是最基本的语言。我没否认其他语言的地位和作用。各种语言都有其“用武之地”。

作者: 2011grassll    时间: 2017-9-13 09:10
本帖最后由 2011grassll 于 2017-9-13 10:40 编辑

一门语言好用，能够令人满意的完成任务，才是程序员选择它的理由，而重量级应用也就会因此不断的产生。

go语言标准库中的网络部份很令人称道，事实上已经是各种云平台的重要选择，国内大家熟知的BAT京东等都有用到，创业公司用的就更多。
另外有个docker，在容器领域中独占鳌头，算得上是一个重量级应用。
而这些只是应用的几个方面，一门语言能做的还有很多。

c,c++在接近硬件的层次是无可匹敌的（虽然我觉得写起来有点不那么愉快），go更偏向应用层。

@gnuxwy：bash类脚本在某些方面和操作系统交互很方便,而用bash本身的语法写逻辑是很烦的。

@不点大大：ken thompson也在go语言的创始团队中
作者: 不点    时间: 2017-9-13 13:29
2011grassll 发表于 2017-9-13 09:10
一门语言好用，能够令人满意的完成任务，才是程序员选择它的理由，而重量级应用也就会因此不断的产生。

...

谢谢指点。原来是 Ken Thompson 开发了 Unix 和 C 语言。好厉害。

很遗憾，我目前没有对 go 语言感兴趣。
作者: 2011grassll    时间: 2017-9-13 17:46
本帖最后由 2011grassll 于 2017-9-13 18:55 编辑

也没啥，有需求才有缘份，如果我不是有一个场景用c太累人，用python性能不够，也不会尝试go的
作者: gnuxwy    时间: 2017-9-16 00:32
屮可不氏什么大神。。。一个菜的不能太菜的编程瞎玩者而已。比起不点大师和楼上的grassll坛友，可能连门都
没有进过。只氏十几年来也多少也接触过好几种语言。。。

和不点一样BASIC也是NN年前接触过，还买过一本小书叫趣味编程一百例吧，小霸王学习机玩过几天就弃了。

后来有VB，也氏玩了几天。再后来就氏pascal，为了考试，断断续续学过一年，后来玩delphi，又用过两个月。

再后来继续考C和C++，又学过年把，也玩过VS2006。。。操，到处找稳定的破解版。
嗯，听说java不错，比Cjj语法漂亮。。。天啦，eclips怎么这慢啊。。。弃之。
别人送了一本C#的书，噢，微软版的java，要不要试试呢？。。。还氏不折腾算了。。。

你瞧，屮氏接触过好几种编程语言吧。。。浅尝辄止的接触。
当然，没一个用得熟的。自已练习写的小程序，最多也不过几百、几千行代码。

后来，偶尔接触到gnux/ubuntu，原来除了windows，还有其他的操作系统可用啊！
而且系统竟然不免费配送木马、病毒、流氓、间谍，也没有一大堆垃圾打包进来！！
不要钱的正版系统还这么好用？----后来当然知道，钱氏不要的，要的氏花点心思和时间熟悉、适应新系统。

正好接触gnux时年纪大了，不怎么玩游戏了，干净的gnux系统正合屮意。
要玩命令行，bash多少要学点。写点小程序，再把C捡起来重新再学下。。。

请问不点大师和grassll坛友，glib的库很完善很强大，但氏怎么没有中文手册啊。。。屮英文水平比较烂。
屮有一本纸质的linux的C函数手册，很有用，但远没有glib的库函数那么全面实用，可一直找不到中文手册。


作者: 不点    时间: 2017-9-16 07:58
楼上 gnuxwy 过谦了。光是你的经历，都有着压倒性的优势，本人差很远，不值一提。我除了业余自学 BASIC、C、汇编，没再学过别的语言，虚度光阴了。也没参加过任何种类的计算机水平考试。

Linux、开源，其最大好处是，让像我这样“下三烂”水平的人，能够“喘一口气”、“呼气点新鲜空气”、“找到自己的存在感”——别小看了这一点，我认识到，“刷存在感”是人生的一个基本需求。绝大多数人都被淹没在汪洋大海之中，不显眼，缺乏“存在性”。这些人为了证明自己活着还有意义，就要到处寻觅，寻找那些适合于证明自己“存在”的东西。普通人永远都是大多数的，因此，上述这种情况永远不会改变。也因此，“刷存在感”的需求量是很大的，这种“欲望”是消灭不掉的。这就从一个视角再次证明了，Linux、开源是消灭不掉的，就连微软都接受了这一点（尽管它很不情愿）。——以上是今天的感想。有想法就分享出来，也算是证明了自己还活着吧。
作者: 不点    时间: 2017-9-16 13:23
记录一下，cling 的入口文件是这个：

src/tools/cling/tools/driver/cling.cpp

我目前对其交互式操作感兴趣，也就是如下这行代码

  1. Ui.runInteractively(Opts.NoLogo);
复制代码


而函数 runInteractively() 的定义在这个文件中：

src/tools/cling/lib/UserInterface/UserInterface.cpp

其中，关键是这一行：

  1. const int indent = m_MetaProcessor->process(Line, compRes);
复制代码


函数 process 的定义在这里：

src/tools/cling/lib/MetaProcessor/MetaProcessor.cpp

这个函数的代码不多，但比较重要，所以，抄录下来：

  1. int MetaProcessor::process(llvm::StringRef input_line,
  2.                              Interpreter::CompilationResult& compRes,
  3.                              Value* result,
  4.                              bool disableValuePrinting /* = false */) {
  5.     if (result)
  6.       *result = Value();
  7.     compRes = Interpreter::kSuccess;
  8.     int expectedIndent = m_InputValidator->getExpectedIndent();

  10.     if (expectedIndent)
  11.       compRes = Interpreter::kMoreInputExpected;

  13.     if (input_line.empty() ||
  14.         (input_line.size() == 1 && input_line.front() == '\n')) {
  15.       // just a blank line, nothing to do.
  16.       return expectedIndent;
  17.     }

  19.     //  Check for and handle meta commands.
  20.     m_MetaParser->enterNewInputLine(input_line);
  21.     MetaSema::ActionResult actionResult = MetaSema::AR_Success;
  22.     if (!m_InputValidator->inBlockComment() &&
  23.          m_MetaParser->isMetaCommand(actionResult, result)) {

  25.       if (m_MetaParser->isQuitRequested())
  26.         return -1;

  28.       if (actionResult != MetaSema::AR_Success)
  29.         compRes = Interpreter::kFailure;
  30.        // ExpectedIndent might have changed after meta command.
  31.        return m_InputValidator->getExpectedIndent();
  32.     }

  34.     // Check if the current statement is now complete. If not, return to
  35.     // prompt for more.
  36.     if (m_InputValidator->validate(input_line) == InputValidator::kIncomplete) {
  37.       compRes = Interpreter::kMoreInputExpected;
  38.       return m_InputValidator->getExpectedIndent();
  39.     }

  41.     //  We have a complete statement, compile and execute it.
  42.     std::string input;
  43.     m_InputValidator->reset(&input);
  44.     // if (m_Options.RawInput)
  45.     //   compResLocal = m_Interp.declare(input);
  46.     // else
  47.     compRes = m_Interp.process(input, result, /*Transaction*/ nullptr,
  48.                                disableValuePrinting);

  50.     return 0;
  51. }
复制代码


可以看到，它是逐行处理输入数据的。先处理“元命令”。仅当不是元命令时，才交给解释器去处理。

然而，一旦交给解释器，解释器就把输入数据完全当成 C 语言代码了。如果失败了，那就在解释器里面显示错误。比如说，交给一行 shell 命令，此时，解释器只能显示错误。而理想的情况是：它不急于显示错误，而是尝试调用 shell 来进行 shell 的语法分析。如果符合 shell 语法，那就按 shell 命令对待。否则，先显示 C 语言解释器的出错信息，再显示 shell 的出错信息。

作者: 不点    时间: 2017-9-16 14:03
解释器的处理代码在这里：

src/tools/cling/lib/Interpreter/Interpreter.cpp

代码也不长，抄录下来：

  1.   ///\brief Maybe transform the input line to implement cint command line
  2.   /// semantics (declarations are global) and compile to produce a module.
  3.   ///
  4.   Interpreter::CompilationResult
  5.   Interpreter::process(const std::string& input, Value* V /* = 0 */,
  6.                        Transaction** T /* = 0 */,
  7.                        bool disableValuePrinting /* = false*/) {
  8.     std::string wrapReadySource = input;
  9.     size_t wrapPoint = std::string::npos;
  10.     if (!isRawInputEnabled())
  11.       wrapPoint = utils::getWrapPoint(wrapReadySource, getCI()->getLangOpts());

  13.     if (isRawInputEnabled() || wrapPoint == std::string::npos) {
  14.       CompilationOptions CO = makeDefaultCompilationOpts();
  15.       CO.DeclarationExtraction = 0;
  16.       CO.ValuePrinting = 0;
  17.       CO.ResultEvaluation = 0;
  18.       return DeclareInternal(input, CO, T);
  19.     }

  21.     CompilationOptions CO = makeDefaultCompilationOpts();
  22.     CO.DeclarationExtraction = 1;
  23.     CO.ValuePrinting = disableValuePrinting ? CompilationOptions::VPDisabled
  24.       : CompilationOptions::VPAuto;
  25.     CO.ResultEvaluation = (bool)V;
  26.     // CO.IgnorePromptDiags = 1; done by EvaluateInternal().
  27.     CO.CheckPointerValidity = 1;
  28.     if (EvaluateInternal(wrapReadySource, CO, V, T, wrapPoint)
  29.                                                      == Interpreter::kFailure) {
  30.       return Interpreter::kFailure;
  31.     }

  33.     return Interpreter::kSuccess;
  34.   }
复制代码


它主要是调用 DeclareInternal() 和 EvaluateInternal() 函数，这两个函数也在该文件中定义。函数的返回值表示“成功”或“失败”。


作者: tt911    时间: 2017-9-16 18:11
俺一共写过三个大些功能完善的程序
1，第一个按键精灵写的
2，第二个 ahk写的
3，第三个delphi写的
作者: 2013olly    时间: 2017-9-18 09:51
gnuxwy 发表于 2017-9-16 00:32
屮可不氏什么大神。。。一个菜的不能太菜的编程瞎玩者而已。比起不点大师和楼上的grassll坛友，可能连门都
...

估计是因为中国搞底层开发的并不多，所以没有去翻译吧，大部分的编程文档都只给了英文的，都是爱好者去翻译的，qt之类的官方也只有英文文档吧

另外，真正做底层开发的，估计英语也学的差不多了，或者比较了解底层知识，再加上一点翻译软件就基本能够读懂了
作者: 2010eflying    时间: 2017-9-18 12:08
能不能跟不点大师学，肯求不点大带路
作者: 不点    时间: 2017-9-18 23:36
2010eflying 发表于 2017-9-18 12:08
能不能跟不点大师学，肯求不点大带路

不要跟我学。我还想跟别人学呢。我虽然也（像毛主席一样）爱人民，但我可不是那带路人。我虽然也是“为了建设新中国”，可我不能“领导我们向前进”。

说实在话，我还真幻想着有懂开发的高手凑过来，整合出一个好用的编程语言。

目前我觉得 cling 很不错。zsh 又比 bash 强大。因此，我在考虑，最好能整合出一个新的 shell，具有 zsh 和 cling 的功能。

先不说难度有多大，只说这事有没有可能干成。——绝对有可能干成——因为闭源的 Ch shell 就正好支持 C 语言代码的解释执行。所以，开源的整合，肯定有希望成功，只是需要时间罢了。

作者: 不点    时间: 2017-9-19 13:23
今天有一点认识，那就是，不用考虑某一个软件、某个东西有多少用户。用户的多少，不是判断一个东西好坏的唯一标准。有些东西，注定用户不多。比如 Linux 可能就是这样。Ch 这种语言，也没有太多用户，我个人感觉，其用户数量甚至比 Linux 用户还要少。然而，它达到的那种高度，目前是无可替代的，是一流水平。只要你喜欢的、需要的，那就是最好的。就像真理一样，你认为啥是真理，那它就是真理。
作者: 2010eflying    时间: 2017-9-19 16:19
自要是自己用得到的就拿来用
作者: gnuxwy    时间: 2017-9-21 00:58
不点老大也觉得zsh好啊。。。最近看了网上些文章，也觉得zsh真心功能比bash强不少。
也许bash几十年的首选地位真的要受到zsh的挑战了。
若不点老大能把C解释执行的功能加到zsh中去，肯定能给zsh大大加分。

话说中国的计算机教育太过捧微软的臭脚了。。。
记得以前参加计算机实践课考核时，机房里所有系统全氏windows(估计也全氏盗版)。
屮说屮的C语言程序要在gcc下编译，监考的女老师睁大眼睛望着屮，
“gcc氏什么编译噐啊？”屮解释说氏gnu的编译噐，她不知gnu氏啥，好在另一个监考的男老师倒氏知道。
说明学校的机房里没有gcc编译噐，最后屮只好用自带的网络本编译程序了。

还有考数据库时，非得指定用微软的sql2000做范例数据库，结果写查询语句时，sql2000不氏与标准sql语言
完全一致的，时间又紧，结果数据库实践课不及格，下半年再补考。补考前为了装上盗版的sql2000，折腾的要
死，装了N个版本，失败了MM次。碰运气才在某台机上安装成功。真不明白，大把的开源数据库不用，非得吊
死在微软的sql2000这个不使用标准sql语句的数据库上。个人觉得，作为考核sql语句，sqlite最合适不过了。

真心希望，gnu编程环境以后在计算机教学中能成为重要组成，除了对微软不利外，各方面都有好处。





作者: gnuxwy    时间: 2017-9-21 01:03
2013olly 发表于 2017-9-18 09:51
估计是因为中国搞底层开发的并不多，所以没有去翻译吧，大部分的编程文档都只给了英文的，都是爱好者去翻 ...

windows的各种开发手册就不少。其实glib确实氏很好的强大全面的C库，也能跨平台使用。
主要还氏中国gnux程序员规模不够，影响力不够，所以这么好的C库，没有中文手册，确实太遗憾了。
作者: 不点    时间: 2017-9-21 06:32
你的意思，我试试理解一下。你是说，中国的计算机教育，就是在给微软培养打工仔。学生毕业之后，只能以各种方式去给微软打工。

存在皆合理。为了达到上述效果，微软也是花了本钱的。我分析（其实是八卦），微软采取了两个关键举措。其一，纵容盗版，让微软系统的普及尽可能达到 100% 的程度。其二，从上游公关，控制国家或学校、企业的高层，令其乖乖听从微软指挥。想想看，中国这样的体制，能抵挡住微软的进攻吗？根本就不能。其实不只是中国不行，放眼世界，别国也照样抵挡不住微软的进攻。无论哪个国家，都有官僚体制。谁能举个反例，说某个国家完全没有官僚体制、完全能够抵挡微软的进攻？一个都没有！就连欧洲的反垄断调查机构，都可以被收买。不服不行。所以我说，存在皆合理，不用纠结，不用去追究。

中国要崛起，路还很漫长。扳指头算算，现有的几个巨头，表面上多么光彩、多么华丽，其实它们的内核、实质，却都是别人的奴才。它们是国人的主子，却是别国人的奴才。它们无一例外地——要么是微软的奴才，要么是苹果的奴才，要么是谷歌的奴才。不知道这些奴才们，将来会不会有《从奴隶到将军》的一天。依我目前的观察，很难，没什么希望。打个比方：就算皇帝死了——皇帝的位置空着——一个奴才也不敢想着去做皇帝。你更不能指望这个奴才能够秸秆起异去打败皇帝。奴相十足，这也是国人的一种存在，因此也是合理的。

另一方面，微软统治世界几十年之后，却遇到大麻烦了。从表面上看，正如前面的分析，微软还能用各种公关手段买通上层官僚，压制其他竞争对手（包括“开源”这个最大、最根本性的敌人）。而其实，这已经暴露出微软的空虚了——是不是在唱《空城计》？纯粹靠“压制”，能维持统治吗？根据历史的规律，这些压制，这些统治，迟早也是要破灭的。微软在垮台之前，肯定要唬人，唬住一个是一个。万一哪天唬不住人了，那时，就轰然倒塌了。

假如一群奴才给微软抬轿，替微软喝彩，你看到了之后，会怎么想？我真的不能揣测别人会怎么想，我只能说说我此刻会怎么想。我会这样想：幸亏那群人里面没有我。人家愿意干啥，那是人家自己的事啊。人家饿了要吃饭，没来找我要钱，我啥也不管人家，我不用替人家操心，我没有任何成本的投入，我也就没有资格去管人家的任何事。那么人家愿意给谁抬轿，抬就抬呗，没什么不可理解的。他给谁抬轿，谁就给他钱，这是公平交易。尤其是，我不能指望人家来给我抬轿啊！假如我那样去幻想的话，那我不就是傻子吗？还有一种可能性，有一部分人可能是被骗去抬轿了，人家并不给钱，或更有甚者，干脆偷偷地把他的肾割掉，卖给医院。网上经常看到被骗的人。这些被骗者，他们被骗了，是他们自己的事情，是他们的造化，是他们的智力或能力使然，你无法去拯救他们。有些人，你能去救。有些人，你不适合去救。有些人，会求你去救他。有些人，根本不想让你去救他（比如想自杀的人）。有些人，你想去救人家，可是人家根本瞧不上你！你都没资格去救人家！人家甚至看你日子过得艰苦，反过来还想救你一把呢！！！！！！诸如此类，等等等等……。大千世界，人有各相，五花八门，难以捉摸。
作者: 2013olly    时间: 2017-9-21 14:09
gnuxwy 发表于 2017-9-21 01:03
windows的各种开发手册就不少。其实glib确实氏很好的强大全面的C库，也能跨平台使用。
主要还氏中国gnux ...

也就是主流的win32有中文手册吧， native api和ddk/wdk的文档我好像也没找到中文版
作者: slore    时间: 2017-9-21 20:51
本帖最后由 slore 于 2017-9-21 20:54 编辑
话说中国的计算机教育太过捧微软的臭脚了。。。


主要是linux系统根本不行好吧.
机房的机器能从老师机器整体控制,能共享桌面操作,linux能?有这种教学软件?
当时连带桌面的系统都没有吧.

大街上拉10个人,有1个用linux都不错了,机房全用linux?出了问题,谁给配置,重装配置网络谁给搞?
老师给你教C语言,数据库,不是来给你搞环境,懂系统管理维护的.
这方面Windows非常傻瓜化,普及,当然用Windows.
如果是学校买的正版的话,服务支持也比linux靠谱的多,交了钱的.

就像你学编程开发,你老师给你教怎么安装Windows,装机器,优化系统服务,改注册表的课么?

学习资料,比如C,结构体,算法不能在linux上用?这些知识是通用的,只不过Windows更方便操作些.
老师要给你教怎么写makefile?要学习make,link命令行?
学校教的基本数据结构,数值,字符串的各种算法,都是通用,反倒根本不给Windows打工,
Windows那么多系统API,谁给你教过?获取窗口句柄,操作控件内容,创建系统服务,更改注册表配置等等,根本没有.

access为什么还有,VF还活着.当时开源数据库不成熟,你说的sqlite数据都是明文不加密的,
商业谁用?虽然是练习学习SQL吧,起码以后会用的环境,微软有ODBC,后面JDBC也有接口,从其他的方式访问.
开源的数据库当时谁厉害?另一家oracle,商业又贵,软件大,功能强配置复杂.谁机器愿意装?

虚拟机软件当时几个人知道,VM又是商业软件,谁给全国老师交钱培训?

现在开源软件发展好了,但是国家体制的人懒,能用就凑合用,不会投入成本更新的,老师也不愿意多学,学生更不会想敲命令.
比如代码管理,SVN,GIT,当时上学不是一个个文件夹复制,打包压缩包?
有给你搭服务器管理么?这个是个好东西,但是即便10年,学校教育是不会给你教的.

咋简单,咋省事再来.相对于linux上,Windows上安装环境还是容易,基本上重装下很多都能解决.
linux不联网,各种库坑死人,有些还得自己编译source.

真心想学习的人,自然有途径和动力去找好的东西,比如开源产品.
大部分,绝大部分人不过应付一个任务而已.对于愿意学习的人没有影响,
对不愿意学习的人省事,没觉得用Windows有什么错.
作者: 不点    时间: 2017-9-22 00:01
各位，这儿主要是讨论具体技术的，不是争斗的地方。

真理永远在自己手上掌握着，难道还怕别人抢走了？

如果对自己掌握的真理有足够自信的话，我认为，应该不屑于去反驳别人。

我只是提醒一下接下来要发帖的朋友，大家要自信一点，尽量不要表现得不自信。

要能够以微笑面对持不同意见者，要有博大的胸怀，容纳不同意见。

假如都能做到这一点，我相信在这个帖子里面，不会有什么争吵。

我建议，就从这个帖子开始，大家试试看效果怎么样，好不好？

作者: slore    时间: 2017-9-22 10:28
不知道是不是因为是Linux区，感觉看Windows有很大偏见。
垄断什么的，这些都没错。
这个世界是通过商业的利益活动运转的。
比如不要法律，纯靠道德约束，能做好的有几个？

Linux的支持者是这些自我约束力好的，但是大部分人还是
受利益驱使的，根据自己的需求也会选择成本低。
Linux不要钱，但维护，学习，其他软件这次根本不能满足大众需求。
电视看过Linux的广告?大部分人不接触，怎么让人会去使用？

即使微软倒了，我不会有那种我当时是Win阵营而感到悲哀。
有段时代是Windows的，这个是改变不了的历史，是因为
其他的发展不能满足人们的需求，不能因为一个东西未来
强大，而否定当下它的对手所发挥的作用。
没有微软视窗，整个行业发展，工作效率是什么样的想过么？
有那么层次不穷的软件，开发者？互联网，WEB，移动技术的繁荣不知道推后多少年。

技术者，会自动适应到新的阵营。和用了BB机，淘汰了，用功能机，
功能机淘汰了用智能手机，优胜劣汰的社会，往前看就行了。

也没有什么争论，只是觉得看问题不要片面的从个人出发。
你这个帖子，还是以你的笔记，技术出发吧，请继续。
作者: 不点    时间: 2017-9-22 11:50
Slore 说得对，没什么可争论的。随着每个人接触面的不断扩大，大家最终都会有差不多统一的认识。差别永远都会存在，但总体的规律也是有的，世界发展的方向也是有的。随着时间的推移，每一个个体，都会有新的认识和发展。原来不统一的，有可能逐步统一。原来有分歧的，有可能逐步融化、消散。而自己原来理解不动的，有可能理解了、接受了。实践是检验真理的标准，而人的观念不是的。人的观念只是自己认定的真理而已，代表不了别人。每个人所看到的世界，都是片面的。一个人无法全面。那种“全能”的东西，可以定义为上帝，或神。人不是上帝，不是神。人都是片面的，都是从片面出发的。当一个人说别人片面的时候，他如果足够聪明，应该意识到他自己也是片面的。以上是自己一点浅见，和朋友们分享。
作者: gnuxwy    时间: 2017-9-24 00:30
噢，想不到屮这个菜鸟的对编程学习过程的一段感概，还能引出老大们的大段评注啊。

其实屮的意思倒不氏喷微软的windows系统本身，虽然屮不怎么喜欢用它，但从不否认它氏成功的商业操作系统。即使现在微软大不如前，windows在pc仍然氏占统治地位的，以后再过几十年仍然如此。

不过slore坛友以为以前没有windows，就不会有计算机行业发展，那就太想当然了。微软发家史就不用提了。看看现在的移动领域就知道。没有微软称霸，智能手机软硬件一样发展很好。

对包括计算机行业在内的许多行业来说，垄断对消费者从来不氏好事。当然现在谷歌想垄断智能手机也氏做不到的，有了PC领域内的教训，谷歌也很难做到。

回到屮唝过的计算机编程教育来说，这点屮个人始终认为，还氏不要专捧微软的臭脚为好。
程序员本来就专敲键盘的，所以对普通电脑用户望而生畏的基本命令操作，对程序员而言，不氏问题。
至于教育程序员的老师，他本来也应该学的，又不氏微软给他发工资，干吗专教微软的东西。

以开源系统为范本进行编程教育，显然总成本、长期成本要占优。进行学习的程序员，会对整个系统构建和程
序的开发的完整过程，会有更深入的认识和体会，对各种开发工具和库的应用更熟练些。对适应各种软硬件平台
的差异也会更自然处理。至于在此基础上使用一些更昂贵的商业系统，自然更不在话下。

屮氏从一个完全的windows游戏用户，由于各种偶然因素才成为gnux普通用户的，当然，也算氏个菜鸟程序员，
，手拿命令手册、函数手册，写点简单的小程序也做得到。基于屮本人以前的经历，所以感觉对于编程教育、
编程爱好者而言，开放系统氏更好的选择。普通windows用户，屮氏绝不会向他们推荐要动手能力的系统的。




作者: 不点    时间: 2017-9-25 05:59
经过这么多天的尝试，企图整合 zsh 和 cling，失败了。失败的原因在于，自己吃不透 zsh，感觉 zsh 的代码就像迷雾，我完全找不到方向，失踪了。

接下来只好老老实实地，安心折腾 bash 了。还好，初看起来，bash 的代码结构很清晰。

作者: liaoyin    时间: 2017-10-9 09:23
不点大侠的心路历程......
披肝沥胆呀！
我无语了。
作者: 不点    时间: 2017-10-10 09:35
liaoyin 发表于 2017-10-9 09:23
不点大侠的心路历程......
披肝沥胆呀！
我无语了。

谢谢您的评价。我的言论和行为，要尽力做到不伤害他人，同时我自己也要达到不被他人伤害的高度；而且我还进一步希望，其他人也能从我这里得到有益的东西，就是说，（假定他们原先没有做到的话，今后）他们也能做到不伤害他人，以及不被他人伤害。

上述道理很简单，但做起来很不容易。首先，“不伤害他人”，这一点就做不到。我以前伤害了一堆一堆的人，不计其数。后来好不容易发现了这个严重问题，想挽回，但有点晚了。即使在企图挽回的过程中，我也在不由自主地继续伤害他人，那是因为水平低，没有经过岁月的锤炼，知识和认识都不牢固。随着时间的增加，我越来越成熟了，越来越少去伤害他人了（但我觉得我永远也达不到 “完全不伤害他人” 的高度）。

不被他人伤害，这也做不到。他人要来伤害你，你可能是猝不及防。甭说防人防不住了，就连动物，都防不住。我每年都被蚊子咬，防不胜防。连动物都防不住，还能去防人？根本防不住。但正因防不住，所以才需要去防，所以这个 “防” 就有了价值，很重要。人的狡诈远比动物厉害得多。

我希望我有价值，我希望我是存在的。如果我没价值，那么我就是不存在的。我需要刷存在感。一个人的价值，就体现在他对别人有什么用处。你对别人有用，别人就会想起来你，你就存在，你就有价值，否则，你就不存在，你就没价值。假如你要伤害别人，那么，你不仅没价值，你还令人讨厌，你的价值是负的，别人甚至有可能盼着你死去。活着是干啥？那不是有存在感吗？如果连存在感都没了，那活着还有什么意思？当然了，不同的人，对活着的意义以及对存在感的认识，可能是千差万别的。在现实世界中，我们也能碰上这样的人（虽然不多），他们以伤害别人为荣耀，他们认为这样才显得自己是存在的。他们用不断地伤害他人的方式，来显示自己比别人强，来证明自己是存在的。他们活着的意义，就是伤害他人、压倒他人，占领他所认为的 “人生制高点”，以此为乐。我并非痛恨这样的人。他们也是一种存在，而存在是合理的。我坦然地跟这样的人打交道。他们很聪敏，但他们并不去试图伤害我。当他们遇到困难的时候，我还尽力去帮助，替他们出主意、想办法。但我的主意和办法，很少被他们采纳。其实我不知道他们采纳不采纳，他们从未明确表示采纳了，从未有感谢的意思，我据此猜测，他们可能没有采纳。他们之所以乐此不疲地去伤害他人，是因为他们很不幸，他们在童年的时候，深深地被别人伤害了。这种痛苦，导致他们后来要倔强顽强地去生活，走到极端，那就是去不断地伤害他人。他们的可怜之处在于，永世跳不出这个怪圈。他们不能做到，把恨转换成爱，这样的转变，对任何人都是一件困难的事情，对他们也一样困难。比如，在我经济困难的时候，我的自行车被偷了，我很难受，我那时就很想去偷一个自行车，只是没胆量。不像现在，经济条件好了，也不会在乎自行车被盗了。所以，一个人心态的转换是很困难的一件事，条件不成熟，是不可能转换的。而把自己的痛苦，转换成对大自然的热爱，这个转折的跨度就更大一些，就更难以成行了。不过，人外有人，天外有天，我经常在新闻中、在现实中看到那些高人。

作者: 2011grassll    时间: 2017-10-10 10:20
本帖最后由 2011grassll 于 2017-10-10 10:33 编辑

不点大大的所说的，很契合众生平等、内圣外王、为而不争之道啊
我经常看南怀瑾先生的书，谈儒释道的功夫和修养，修心又养生，很有意思
作者: asmcat    时间: 2017-11-9 23:22
本帖最后由 asmcat 于 2017-11-9 23:28 编辑

机器学习带动了python,现在这货很火,非常火
http://finance.cngold.org/c/2017-08-08/c5226954.html
Python 的排名从去年开始就借助人工智能持续上升，现在2017年它已经成为了第一名。但排在前四名的语言 Python、C、Java 和 C++都拥有广大的用户群体，并且他们的用户总量也十分相近。

编程语言不能独立生存,而做为工具生存,然后才有独立的语言研究,
退一步说,工具本质决定了编程语言当前地位,就是能干什么,语法是次要的
相对于快速现成的引入包,语法优势微乎其微.
作者: jmc06    时间: 2017-11-18 18:37
本帖最后由 jmc06 于 2017-11-18 18:43 编辑

不点大大，能问您个人问题吗？
一直很想知道您的年龄和从事的职业，
通过看你的很多帖子和回复，我发现您有很多时间搞研究，而且曾维护过grub4dos，但总感觉这些花了很多时间的研究也都仅仅是个人爱好，那什么事业可以让您有这么多时间来搞这些呢？在现实生活中也是从事这些工作的吗？还是完全不相关呢？
无法勾勒出对您的完整印象。。
您说现在精力有限，身体条件也不允许，是因为您岁数很大吗？
作者: 不点    时间: 2017-11-18 18:48
jmc06 发表于 2017-11-18 18:37
不点大大，能问您个人问题吗？
一直很想知道您的年龄和从事的职业，
通过看你的很多帖子和回复，我发现您 ...

谢谢您抬举。但很抱歉，个人信息在当今网络时代属于敏感、隐私，不便透露。通常骗子会打这个主意，建议您也倍加小心。要做到两“不”：既不打听别人的隐私，也不给别人提供自己的隐私。

作者: jmc06    时间: 2017-11-18 19:19
不点 发表于 2017-11-18 18:48
谢谢您抬举。但很抱歉，个人信息在当今网络时代属于敏感、隐私，不便透露。通常骗子会打这个主意，建议您 ...

对不起，冒犯了。。
作者: hs6688    时间: 2018-1-9 20:37
严重支持
作者: qzwhok    时间: 2018-2-16 07:41
我还是比较喜欢纯中文编程，由26个字母排列组合表达函数意义不清晰，如果想表达清晰每句的涵义，就得搞一长串的字母组合，搞程序代码密密麻麻一大版，眼花缭乱，代码可读性极差，要花很长时间理清单词，出错率很高，而中文有几千汉字，排列组合出的代码要短很多，意义表达力强。最低级语言代码只有1和0两个符号排列组合编码组成，可读性最差。次之是，低级语言由0～9,a,b,c,d,e,f十六个符号排列组合编码组成，而由26个字母加上一些符号组成的代码的可读性仍然差，从这种意义上讲，中文编程是更高级，建义国人大力发展中文编程语言，少转弯路
作者: qzwhok    时间: 2018-2-16 07:59
目前缺少 直接把中文程序代码 编译到十六进制可执行文件的高级语言编译器
作者: 不点    时间: 2018-2-17 09:21
汉语、英语，各有优势。

英语——初学时简单，用 26 个字母进行组合，拼音式的学习，上手容易。缺点是进阶成问题，词汇量太大，语法结构复杂。懂英语的国家多。

汉语正好相反，初学不容易，需要学会两三千字才能读书看报。但进阶快，没有复杂的语法。懂汉语的人数多。

两种语言都很优秀，互相成为补充。

英语适合用来编程。如果都用汉语，则只能让少数几个国家的人看懂，不利于程序代码的推广。

作者: slore    时间: 2018-2-17 12:40
qzwhok 发表于 2018-2-16 07:41
我还是比较喜欢纯中文编程，由26个字母排列组合表达函数意义不清晰，如果想表达清晰每句的涵义，就得搞一长 ...

函数化，10～30行，好的代码不需要明白每个变量意义，英文代码很容易懂，全部中文笔画多，关键字，逻辑内容只只有空格隔开，对内容识别脑子要消耗更多分析，屏幕才乱。没有大小写，划分不清晰。
创建 中文类（）；
new 中文类（）；
面积 = 边长*边长*派;
r*r*PI;
PI,p,pi的含义可以区分，用中文，要区分要变量派，常量派？
5笔，拼音都比实际中文要输入的多，一个如果英文就是if。打字速度是固定的，用中文开发效率减半，搜索，重构替换代码时，输入法切换等问题也有。而且现在开源发展好，中文轮子你要自己造。
你用中文写代码，大点项目跟写论文一样，你先写个1万行的中文代码试试，不管能不能运行，按你自己的语法，好懂的写，实现某个功能逻辑就行。
代码量越大，中文维护比英文维护要辛苦更多。
作者: qzwhok    时间: 2018-2-19 00:07
slore 发表于 2018-2-17 12:40
函数化，10～30行，好的代码不需要明白每个变量意义，英文代码很容易懂，全部中文笔画多，关键字，逻辑内 ...

个人觉得，在代码输入方面是英文是快，必尽字母都是直接在键盘上，但搞定一个程序不只是依靠代码敲的快，调试程序往往也很花时间，而长长一串字母排列错误或少漏更难发现，而且很多时候都是靠人工检查，一个错字比一串字母好发现，甚至有时为代码名字都取穷，组合又组合。如果是中文，不会很长，一眼就能识别好几行。如果是别人写的代码，加上是英文写的话，理清代码单词和代码用意也费时较多。如果别人写的是上万行密密麻麻的英文单词代码，几乎不想去理它。而且英文代码和编辑环境，对国人来说要多花几年的冤枉时间来学，别人便赢得了几年的优先时间，最终结果是永远根在别人的屁股后面。如果全部度有纯正中文版，包括底层系统及编译器，错误提示等等。国人可省去背英文单词的时间。
作者: 不点    时间: 2018-2-19 08:41
qzwhok 发表于 2018-2-19 00:07
个人觉得，在代码输入方面是英文是快，必尽字母都是直接在键盘上，但搞定一个程序不只是依靠代码敲的快， ...

有些东西属于 “历史遗留”。历史使然，难以更改。

电脑是西方发明的，不是中国人发明的，起初只支持英文。欧洲语言接近英文，所以后来很快也支持欧洲语言了。所谓 “多国语言支持”（multi-lingual support），当初实际上仅仅是指对欧洲语言的支持（现在可能仍是这个含义）。写着 “亚洲语言支持” 的，才是真正支持全球语言的，因为只要支持了亚洲语言，就是支持了 unicode，其它语言都顺便支持了。

待到支持亚洲语言，已经太晚了。Unicode 的出现也更晚。即使现在，大多数主板的 bios 设置程序仍是英文的。

英文只有 26 个字母，整个 ASCII 码也只有 128个，字模占用的空间小，可以放在 ROM 里面。如果要支持中文，按照 Unicode 基本字符集 65536 个字符计算，光是那字模空间就需要 2M，远远超过当时 BIOS ROM 的空间。当然，这个字模完全有可能放在显卡的 ROM 里面，供 BIOS 使用，但只是现在才有这种可能性，当初是做不到的（即使现在也没人做，因为 BIOS 也要淘汰了；不过在 EFI 的情况下倒是有可能把字模放在 ROM 中，因为现在的内存空间很大，ROM 也可以很大）。

历史让英语具有 “世界性” 的地位，这是缘分。不要问原因，原因太多，太复杂。编程人员大多数对英语的关键字已经习惯了，习惯成自然。再说了，这几个关键字也不难记住，没必要再费劲去发明一个只有汉语圈的人才能认识的中文关键字，而且不利于西方程序员在 “非 unicode” 环境下使用（那会显示成乱码）。
作者: 不点    时间: 2018-2-24 12:44
趁着年还没过完的这段宝贵时光，坐下来谈谈最近的一些进展情况。前面说了，用 g++ 来编译 zsh、bash 都失败了，无法与 cling 对接。

虽然 dash 成功改造成可以用 g++ 编译，但是在与 cling 对接时，感觉困难仍然很大，也只好放弃了。dash 代码虽然不算很大，但与 zsh 和 bash 一样，也是太复杂，换句话说，就是乱糟糟的，看不懂。

在这期间，我还找到了另外几个 shell，比如最简单的 yash，以及目前仍在活跃开发中的 “s” shell。

其中，yash 对我的影响最大。它用简单几行代码，就展现了 shell 的最重要的一个特征：命令解释器。

目前我不打算整合某个 shell 到 cling 中了。我打算仅以 yash 作为启发，先给 cling 添加 “命令解释器” 的功能，然后逐步完善，看看最终能否达到一个常规意义下的 shell 的目标。暂时不考虑 POSIX 规范。刚才提到的 “s” shell 的开发者也不考虑 POSIX 规范。闭源的商业 shell ——  Ch shell 也不完全支持 POSIX 规范。

Cling 是以 C 为主要工作目标的，它处理的对象是 C（C++） 语言的代码，它不是以 shell 为目标的。当我们想要让它处理 shell 命令的时候，我们遇到的一个困难是，如何能让它区别 shell 命令和 C 语言代码。如果无法区分，那么究竟是先以 shell 对待，还是先以 C 语言对待？执行效率问题，也需要考虑。如果先以 shell 处理，则有可能在磁盘上寻找外部命令，这对于本来就是 C 代码的情况，速度影响很大。如果先以 C 代码来处理，那么，它作为 shell 命令解释器的功能就会淡化，效率也不会好。要解决这些矛盾，必须付出一定的代价，要有某种取舍。

Cling 是个完善的 C 语言环境，能够识别出由 “#” 开头的预处理指令。而在 shell 中 “#” 通常用做注释符。C 的注释符是 “//” 以及 /*...*/，但在 shell 命令中有可能出现这些字符（例如 wget http://www.baidu.com/ 以及 ls src/*；ls */ 等）。

如果权衡的话，可以把 “#” 开头的行都按照 C 语言来处理，取消 “#” 的 shell 注释符功能。由 “#” 开头的行，如果不是有效的预处理指令，C 语言处理模块会报错。报错以后， 我们不再交给 shell 模块继续尝试执行（既然发现它是 “#” 开头的）。也可以考虑设法禁止 C 模块对于未识别的 “#” 预处理指令报错。

cling 是 C 语言的工作方式。如果把它当成 shell，则需要是 shell 的工作方式。命令行究竟是以 C 方式的处理优先还是以 shell 方式的处理优先，这也需要考虑。

如果权衡的话，可以在刚启动 cling 时，确定默认的工作方式为 shell，当按照 shell 命令执行失败时，再尝试按照 C 语言代码去执行一次。但是，对于那些特殊的行（比如行首有 “#”，或行尾有续行符 “\”，或行尾有事先设定的标志 “//”），就能够确定按照 C 语言来对待，不按照 shell 命令来对待，这样就避免了歧义，提高了工作效率。

对于那些 #include 进来的代码文件，或者将要执行 .c, .cpp, .h 之类的文件，可以调整默认工作方式为 C 语言方式，即，先当作 C 语言代码来处理，出错时，再尝试执行 shell 命令。如果执行其他后缀（比如 .sh）的文件，则采用默认工作方式为 shell 命令方式。当 C 方式的文件或子程序执行完成后，默认的执行方式又回归调用者所采用的方式。
作者: 不点    时间: 2018-3-2 12:50
有谁愿意共同折腾 cling 的，请在此留言。
作者: jianliulin    时间: 2018-3-10 00:16
微软的power shell 用起来就很不错
作者: ge    时间: 2018-3-10 10:20
qzwhok 发表于 2018-2-16 07:41
我还是比较喜欢纯中文编程，由26个字母排列组合表达函数意义不清晰，如果想表达清晰每句的涵义，就得搞一长 ...

你还觉得中文太难吗？颇 好 佳 优 良都要收入吗？还是只允许一种说法？其它的不行吗？本来一个英文编程几M到几十M可以做到的要几百或者上千M才完成？在我一点不了解的时候也想过！后来就！呵呵！好多人说我！不过我现在也不会编程！好多东西不明白！不知道向谁问就没有继续！这个又不是说英语！只要知道关键字就可以了！
作者: ge    时间: 2018-3-10 10:23
qzwhok 发表于 2018-2-16 07:41
我还是比较喜欢纯中文编程，由26个字母排列组合表达函数意义不清晰，如果想表达清晰每句的涵义，就得搞一长 ...

传统芯片不知道哪时就被淘汰了！国人不要弄这个劳民伤财的东西了！你以为中科院弄不出来你想要的东西吗？我觉得他们是不愿意做而已！
作者: ge    时间: 2018-3-10 10:31
这个世界说汉语的人最多！但是几个国家呢？还是说英语的国家最多！英文比较简单！我没有学好英文的原因只是我汉语都不懂！名词动词形容词都是什么鬼？我都初中毕业了还是什么都不会！会的只有数理化！具体应用都不清楚！后来打工时才知道用处！但是没有学过立体几何！所以很吃力！不过后来在脑子里一分析才知道都一样的！
作者: anxiang    时间: 2018-4-24 20:10
老大们，如果从底层硬件改起，以0~65535作为超级ASC码，并把中文字归入其中，用作编程写代码，内存单元也按“字”作为单位来计算和访问，26个字母和符号也用字表示，去掉传统西方“字节”模式。假如这样做能不能做到完美实现 中文编程？
作者: atoms    时间: 2018-11-2 13:19
语言只是一种工具，搞艺术，跟工具无关~
作者: 剑客行    时间: 2021-9-23 18:22
这不是艺术，是技术吧
作者: guyanqiu    时间: 2021-10-30 20:16
继续来学习了
作者: guyanqiu    时间: 2022-2-12 22:57
谢谢分享
作者: uos    时间: 2022-3-2 19:03
谢分享
作者: linuxfan    时间: 2022-11-11 14:55
继续来学习的.
作者: 大宝剑    时间: 2022-11-14 09:15
新语言替代慢
作者: jinslaaa    时间: 2022-11-23 23:24
继续研究下吧
作者: 不点    时间: 2022-11-27 14:43
各种编程语言的优缺点

https://cloud.tencent.com/developer/article/1925981

这是腾讯云上的一篇文章。文章虽然很短，但我觉得不错。

文章只提到了 C、Java、C++、Python、PHP、JavaScript、C# 这 7 种语言，没有涉及较新的 Rust 之类的语言。这从一个侧面说明，目前那些较新的语言，并不具有什么“替代优势”，仅仅是 “增加了一种选择” 而已，意义不大。

文章把 C 说成是 “万物之源”，我觉得有深度，这提醒得好。文章还把 “难度” 排在显眼的位置，我也十分认同。一个语言好不好，还得看学习的难度。你一个人偏爱某种语言，那是你自己的事，别人无权干涉。一个语言，如果学习者愿意学、愿意用，这才是属于他的语言。你用的语言，别人不用，即使你写文章强力推荐，别人仍然不用。

除了 “难度” 以外，我觉得还有一个方面比较重要，就是，这个语言的设计实现，是否简单。简单才是美。你一个语言的实现，需要若干兆、若干G 的存储空间，这能是好语言吗？我对此持否定的态度。千年、万年以后的人类，应该是使用设计得更精妙的、更简单易用的语言。

下面就抄录原文，免得大家还得点击上述链接。

-----------------------------  以下是原文  -------------------------

各种编程语言的优缺点

作者：大雄
原始发表时间：2021-12-23


1、 万物之源 C 语言


难度：★★★ 人气：★★★★★
C语言是一种通用型命令式计算机编程语言，其支持结构化编程、词汇变量范围与递归，同时亦是套能够预防各类未预期操作的静态类型系统，最初构建目标在于编写系统软件。
用途：软件开发、硬件、操作系统。
优点：
1.可移植性：无需或者很少改动就可以将开发出的软件在不同平台上运行
2. C语言完全基于变量、宏、函数以及结构，因此可被嵌入至几乎一切现代处理器，从冰箱到闹钟即可作为其运行平台。
3. 了解C语言，也就了解了关于编程语言的一切，几乎所有现代编程语言都脱胎于C，因此了解C语言能够帮助大家快速掌握其它各类编程语言。
缺点：
1.运行时C语言不具备运行时检查机制。
2.面向对象编程: C语言不支持面向对象编程，因此C++才会诞生以解决这一问题。
3.复杂的学习曲线: 越是基础的东西并非最易上手，比较适合那些已经对其它编程语言有所了解的学习者。

2、 Java


难度：★★★ 人气：★★★★★
Java 的热度一直居高不下，长期霸占各类编程语言排行榜前三名。Java 是一门面向对象的编程语言，开发者可以利用其在计算机上创建应用程序。
用途：安卓、iOS开发、视频游戏开发、桌面GUI、软件开发。
优点：
1、需求旺盛，Java开发岗位为目前需求量最大的软件技能方向，Java也是世界上使用范围最广泛的编程语言。
2、不断发展的语言，Java平台不断迎来新功能，包括 lambda 机制的引入。
3、Android 应用开发的基石：谷歌公司的 Android 移动平台是目前全球范围内人气最高的移动平台，开发者可以利用自己的 Java 技能为 Android 系统开发应用。
缺点：
1、占用大量内存：Java使用的内存量高于C++.
2、学习曲线较长：并不属于最易于上手的语言，当然也不是最难学习的语言。
3、启动时间较长：利用 Java 语言开发 Android 应用时，我们一定会对其模拟器代码在台式机上运行速度留下深刻印象。


3、 C++

难度：★★★★ 人气：★★★★
C++是一款面向对象编程(简称OOP)语言，被广泛视为最出色的大规模应用构建语言。C++属于C语言的一个超集。
用途：软件开发搜索引擎操作系统视频游戏
优点：
1、重要技能：掌握C、C++能够帮助大家在众多开发人才当中脱颖而出，掌握了C/C++大家将能够深入了解Java或Python等编程语言中的内存管理机制，并了解如何回避各类常见的陷阱与难题。
2、灵活的调整空间：C++允许大家对自己的应用进行灵活调整并充分发挥计算机的全部性能。与Java/C++相比，编程过程并不友好，但我们却能够利用它实现一切操作。
缺点：1、艰难的学习曲线：C++非常难于学习，但在掌握之后大家将直接登上程序员金字塔的塔尖。
2、体系极为庞大： C++规模可观且拥有大量极为复杂的功能交互方式，没有哪位开发者能够使用其提供的全部构建组件，但我们可以充分发挥自己的才智选择正确的功能子集。

4、 Python

难度： ★★ 人气：★★★★★
Python是一项服务器端解释型开源非编译脚本语言可单独使用，也可作为django等框架的组成部分。
用途：Web开发、视频游戏开发、桌面GUI 软件开发。
优点：
1、易于学习：Python作为最易于掌握的编程语言而拥有极高人气。
2、库：广泛的工具及功能库能够帮助大家轻松完成构建工作。
3、物联网：Python特随着物联网技术的普及而进一步发展，目前Rasp-bery Pi等新型平台已经将其作为开发基础。
缺点：1、速度：作为一种解释型语言，其速度往往往低于编译语言。
2、移动：Python在移动计算领域的表现比较直观，利用Python开发的移动应用非常罕见。
3、设计：Python语言在设计上存在一些问题，其属于动态类语言，因此需要进行更多测试且带来某些只在特定运行时中出现的错误。

5、 PHP

难度：★★★  人气：★★★★
PHP是一款服务器端脚本语言，社区庞大且活跃，主要面向Web开发但同时作为通用性编程语言。
用途：WordPress插件、Web开发、创建包含数据库功能页面。
优点：
1、易于上手且功能丰富:它是一款适合Web开发与通用用途，易于快速上手的服务器端脚本语言。
2、庞大的社区:PHP拥有庞大的活跃社区。Web开发者面临的大部分难题都拥有现成的解决方案。
3、数据库:可与各类数据库、文件系统及图片顺畅协作。
缺点：1、学习门槛过低：由于学习门槛太低，项目中存在着大量经验不足的开发者，某些开源代码甚至已经存在十余年。
2、速度：PHP为解释型语言，其代码运行速度低于大部分编程语言竞争对手。
3、错误处理机制： PHP的错误处理机制比较糟糕，特别是与其它编程语言相比较，这主要是因为PHP的开发历史过长且需要支持大量旧有功能。

6、 JavaScript

难度： ★★ 人气：★★★★
JavaScript 是一款使用效率最高的客户端脚本语言，这意味着 JavaScript 代码写至 HTML 页面当中，当用户通过内部 JavaScript 请求至 HTML 页面时，该脚本会被发送至浏览器，并由浏览器决定下一步操作。
用途：网站前端、分析、功能控件、Web交互
优点：
1、速度：作为客户端脚本语言 JavaScript 中的任意代码函数却可立即运行而无需等待服务器连接及应答，因此其速度非常出色。
2、易学性：JavaScript 相对易于学习及使用。并且掌握了 JavaScript 语言就等于成为能同时开发网页、后台、移动端的全栈工程师。

3、简单性：JavaScript 能够与其它多种语言顺利协作，并可用于多种不同应用程序与PHP或者SSI脚本不同，JavaScript 可被插入任意网页当中,而无需考虑具体文件扩展名。
缺点：1、安全性：由于代码在用户计算机上执行，因此其有时会被恶意活动所利用正因为如此，部分用户会选择禁用JavaScript。
2、最终用户依赖性: JavaScript 有时会在不同浏览器上以不同方式进行解释。相较于总能提供同样输出结果的服务器端脚本，JavaScript 客户端脚本的可预测性相对较差。不过这一问题并不是非常严重，只要我们在全部主流测览器上对脚本进行充分测试即可。

7、 C#

难度：★★★ 人气：★★★★
这是一款强大而灵活的编程语言。 与其他编程语言一样，它也可用于创建多种应用程序。事实上，C#的功能只受限于我们的想象力。该语言对开发者的操作内容完全不设任何限制，其可被用于交付动态网站、开发工具甚至是编译器等等。
用途：Windows应用、企业级业务应、软件开发。
优点：1、Net库: 全面集成Net库，提供出色的功能与支持库访问能力。
2、可转换性：其基于C语言，因此C#的结构可转移至Java、Objective-C、PHP以及C++等其它语言形式
3、需求旺盛:：C#加Java为目前各企业需求最为旺盛的软件开发技能组合。
缺点：
1、C#并不是最适合新手们进行入门学习的编程语言，其学习曲线非常陡峭。
2、跨平台能力差：由于集成 .Net，因此不具备跨平台能力。


从上面的对比我们不难发现，每种程序语言都有它的优势和劣势，我们在选择编程语言呢，主要考虑几个要点。

1、构建编写网页 推荐：HTML、CSS、PHP
2、开发app   推荐：Java、C++
3、制作视频游戏 推荐：Python、Java
4、对数据进行管理 推荐：C#、PHP、Python
5、进行偏硬件的编程 推荐：C
6、进行科学计算 推荐：Python


当然，我们在实际开发的时候需要我们综合考虑产品需求，在程序运行速度指标、硬件要求、开发周期等方面进行权衡，最终确定编程所需语言。







欢迎光临 无忧启动论坛 (http://bbs.wuyou.net/) Powered by Discuz! X3.3