编译型语言,解释型语言和脚本语言的对比

1 三种类型的定义:

    编译型语言:C,C++。编译后成为机器语言,以后执行的时候就不需要编译了,

    解释型语言;JAVA,C#。在运行的时候将程序翻译为机器语言,虽然Java程序在运行之前也有一个编译过程,但是并不是将程序编译成机器语言,而是将它编译成字节码(可以理解为一个中间语言)。在运行的时候,由JVM将字节码再翻译成机器语言。

   脚本语言:python,php,JavaScript,perl,asp。一般都有相应的脚本引擎来解释执行。 他们一般需要解释器才能运行。

2 C,C++,JAVA,python,ruby的对比

C

虽说C语言在内存管理方面存在严重的缺陷,不过它还是在某些应用领域里称王称霸。对于那些要求最高的效率,良好的实时性,或者与操作系统内核紧密关联的程序来说,C仍然是很好的选择。 

C良好的可移植性也为它加了分。不过现在很多其他的语言可移植性越来越好,C在这方面的优势可能会逐渐丧失。 

现有的很多程序可以产生非常棒的C代码,比如语法分析器、GUI Builder等,这时候C语言也是有吸引力的,因为你所需要编写的代码只是整个程序的一小部分。 

再有,我们当然应该认识道,C语言对于程序员来说具有无可替代的价值。就我这里讨论的每一种语言而论,只要你发掘的足够深,到最后你会看到它们的内核都是用纯正的、可移植的C写成的。 

到了今天这个时候,我们最好把C看成是UNIX虚拟机上的高级汇编语言。 就算是其他的高级语言完全可以满足你的工作需要,抽出时间来学习C语言也仍然有益,它能帮助你在硬件体系的层次上思考问题。 即使到了今天,最好的C语言教程仍然是1988年出版的K&R第二版The C Programming Language. 

总结:C最出色的地方在于其高效和贴近机器,最糟糕的地方在它的内存管理地狱。 

C++ 

C++最初发布于1980年代中期,当时面向对象语言被认为是解决软件复杂性问题的银弹。C++的面向对象特性看相去使其全面超越了C,支持者认为C++将迅速把上一代语言挤到陈列馆里去。 

但是历史并非如此。究其原因,至少有一部分归咎于C++本身。为了与C兼容,C++被迫作出了很多重大的设计妥协,结果导致语言过分华丽,过分复杂。为了与C兼容,C++并没有采用自动内存管理的策略,从而丧失了修正C最严重问题的机会。 

另外一部分原因,恐怕要算到面向对象身上。看起来OO并没有很好的达成人们当年的预期。我就这个问题调研过,我发现使用OO方法导致组件之间出现很厚的粘合层,并且带来了严重的可维护性问题。今天让我们来看看开放源码社区,你会发现C++的应用还是集中在GUI,游戏和多媒体工具包这些方面,在其他地方很少用到。要知道,面向对象也只是在这些领域被证明非常成功,而开放源码社区的选择,很大程度上体现了程序员的自由意志,而不是公司管理层的胡乱指挥。 

也许C++实现OO的方法有问题。有证据表明C++程序在整个生命周期的开销高于相应的C, Fortran和Ada程序。不过,究竟这是否应该归咎与C++的OO实现上,还不清楚。 

最近几年,C++加入了很多非OO的思想,其异常思想类似Lisp,STL的出现是非常了不起的。 

其实C++最根本的问题在于,它基本上只不过是另一种传统的语言。STL中的内存管理比先前的new/delete和C的方案要好的多,但是还是没有解决问题。对于很多应用程序而言,其OO特性并不明显,相比与C,除了增加复杂度之外没有获得很多好处。 

总结:C++优点在于作为编译型语言,把效率与泛型和面向对象特性结合起来,其缺点在于过于华丽复杂,倾向于鼓励程过分复杂的设计。 

Java 

Java的设计很聪明,它采用了自动内存管理,这是最大的改进,支持OO设计带来的好处虽然不那么突出,不过也很值得赞赏,相比C++,其OO设计规模小而且简单 。 

相对于Python而言,Java有一些明显的失误。有些地方设计的还是太复杂,甚至有缺陷。Java的类可见性和隐式scoping规则太复杂了。Interface机制是为了避免多继承带来的问题而设计的,但是要理解和使用它还是挺难。内部类和匿名类导致令人困惑的代码。缺乏有效的析构机制,使得除了内存之外的其他资源(比如互斥量和锁)管理起来很困难。Java的线程不可靠,其I/O机制很强大,但是读取一个文本文件却非常繁琐。 

Java没有管理库版本的机制,从而形式上重蹈了了Windows DLL地狱的覆辙。在类似应用服务器这样的环境里,这引起了大量的问题。 

总体而言,我们可以说除了系统编程和对效率要求极高的程序之外,Java在大部分领域优于C++。经验表明,Java程序员似乎不太容易象C++程序员那样构造过度的OO层,不过在Java中这仍然是个严重问题。 

Java是否优于诸如Perl, Python这样的语言?我们还不是很清楚,很大程度上似乎跟程序规模有关。其擅长的领域基本上于Python相似,在效率上无法跟C/C++相提并论,在小规模的、大量使用模式匹配和编辑的项目里也无法匹敌Perl。在小项目里,Java显得过分强大了。我们猜测Python更适合小项目,而Java适合大项目,不过这一点并没有得到有力的证明。 

Python 


Python是一种脚本语言,可以与C紧密整合。它可以与动态加载的C库模块交换数据,也可以作为内嵌脚本语言而从C中调用。其语法类似C和模块化语言的杂合,不过有一个独一无二的特征,就是以缩进来确定语句块。 

Python语言非常干净,设计优雅,具有出色的模块化特性。它提供了面向对象能力,但不强迫用户进行面向对象设计。其类型系统提供了强大的表达能力,类似Perl,具有匿名lambda表达式,这点又让Lisp黑客们感到亲切。Python依靠Tk提供方便的GUI界面开发能力。 

在所有的解释型语言里,Python和Java最适合多名程序员以渐进方式协同开发大型项目。在很多方面,Python比Java要简单,它非常适合与构造快速原型,这一点使得它对于Java有独特优势:对于那些既不很复杂,又不要求高效率的程序,Python十分合适。 

Python的速度没法跟C/C++相比,不过在今天的高速CPU上,合理地使用混合语言编程策略使得Python的上述弱点被有效地弥补。事实上,Python几乎被认为是主流脚本语言中最慢的一个,因为它提供了动态多态性。在大量使用正则表达式的小型项目,它逊于Perl。对于微型项目而言,shell和Tcl可能更好,Python显得太过强大了。 

总结:Python最出色的地方在于,它鼓励清晰易读的代码,特别适合以渐进开发的方式构造大项目。其缺陷在于效率不高,太慢,不但跟编译语言相比慢,就是跟其他脚本语言相比也显得慢。

Ruby

本来 rails 框架就自带了 server,WEBrick。看着 Log 做开发效率非常高。 如果要部署的话,用 passenger 也是绝对方便。 Views 层的模板系统,ERB 应该比 Python 的各种要来得美,而且更加简单。之前用过 Django,觉得太重了。 Rails 可以让你不断的惊讶程序可以这样写的啊,我第一次看到有 7.days.ago 的时候惊掉了。 Rails强调一种DSL,一来符合人们的语言习惯、二来我觉得是一种编程语言的颠覆,我们并不是在用某个特定的语言(比如Ruby)来实现一个 功能(就如同是用C还是用Java来写一个编译器),而是我可以在这些语言的基础上定义一种新的语言(类似于lex,yacc这样的词法语法生成器)。看 看routes.rb的设置吧,能有多么惊讶,这是程序么,简直就是诗。美不只是在于内容,同样在于形式。

Ruby 或者说 Rails 的缺点或许就是学习的曲线太陡,我之前有过 MVC 的经验,上手RoR 还是花了三周的时间,或许也是自己接受能力不强吧,但更确切的问题应该在于 Rails 的惯用法太多:当然,我在用 ActiveRecord 拿数据的时候,可以写 find_by_sql(“blablabla”),但是细查 Rails 的文档,他是提供类似于 Joins.Group.Select 等等的方法的,姑且不论效率是不是真的会快点,少写一点 sql 在 .rb 的文件里面不是会更美一些么。再到后来,偶然又发现有 metawhere 这种东西,是不是又要忍痛抛弃既往学到的那一堆 works but not elegant 的东西,义无反顾的投身到 metawhere 的学习中。

当然,如果不追求完美,上手也没有这么恐怖。


评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值