为女朋友做的网站,做百度网站好吗,炫酷的html5网站,数据库与网站建设的关系本文来源于我在InfoQ中文站翻译的文章#xff0c;原文地址是#xff1a;http://www.infoq.com/cn/news/2013/01/C-Language 来自Couchbase的Damien Katz认为C依然是非常适合于后端编程的一门语言#xff0c;然而有的开发者则觉得C有太多的瑕疵#xff0c;他们支持C或是Java… 本文来源于我在InfoQ中文站翻译的文章原文地址是http://www.infoq.com/cn/news/2013/01/C-Language 来自Couchbase的Damien Katz认为C依然是非常适合于后端编程的一门语言然而有的开发者则觉得C有太多的瑕疵他们支持C或是Java还有一些人连这两种语言也不喜欢。 在最近一篇题为The Unreasonable Effectiveness of C的博文中CouchDB的创建者Damien Katz表示C依然是非常适合于后端编程的一门语言虽然现在已经有了很多更加现代化的语言如C、Java、甚至是Erlang或是Ruby但他还是非常支持C语言。Katz并不是认为C就是比其他任何语言都要好但在“重点考虑性能与可靠性等场景下C是很难被打败的”——这段话援引自Damien Katz随后的一个帖子旨在澄清自己的立场。 虽然一开始使用Erlang编写了CouchDB的很多代码但在花费了“2个人月来处理Erlang VM中的一个崩溃问题”之后Katz感到非常不爽。 我们浪费了大量时间追踪核心Erlang实现中的一些问题不敢保证发生什么以及原因我们觉得也许问题出现在我们自己的插件C代码中希望我们自己能够发现并修复问题。但事实并非如此这是核心Erlang中的一个竞态条件Bug。我们只能通过Erlang的代码查看器来找到这一问题。对于那些对计算机进行了过多抽象的编程语言来说这是个很基本的问题。 出于这一点以及性能因素Katz决定逐步重写“将Couchbase的代码换成C并将其作为大多数新特性的首选实现语言”。有趣的是C证明了“当我们遇到问题、调试与修复问题时C更具备可预测性。长远来看C的生产力更高”。 Katz列出了对于后端来说C要优于更高层次语言如C、Java等的若干原因 表现力——“C的语法与语义非常强大且具有极强的表现力。凭借C我们既能预测高层算法又能预测低层的硬件。它的语义非常简单语法足够强大能够极大降低认知上的负担让程序员专注在重要的事情上”。简单——“C是一种弱、静态类型语言其类型系统非常简单。我们所说的弱最后会变成一个优点C APIs的“表面”是非常简单且小巧的。相对于大多数框架来说C的一个明显趋势与文化就是创建小型的库对简单类型进行轻量级的抽象”。速度与内存使用——“C是速度最快的语言无论是部分还是完整的基准都表明了这一点。它不仅仅运行时是最快的其内存使用与启动时间也是效率最高的。如果需要在空间与时间上进行折衷那么C并不会对你隐藏任何细节信息我们可以很容易地做出估计”。更快的开发周期——“对于开发者效率与生产力来说最为重要的就是‘构建、运行与调试’周期。周期越快开发的交互性就越好你就更容易处在任务的流态上。相对于所有主流的静态语言来说C拥有最为快速的开发交互性”。调试——对于纯C代码来说你可以查看调用堆栈、变量、参数、线程局部变量、全局变量基本上可以查看到内存中的一切。这是非常有用的特别是当你遇到了问题这个问题在运行的服务器进程中出现了多日并且无法重现的情况下更是如此。如果在更为高层的语言中失去了这个上下文那么你就等着痛苦去吧。跨平台——“有一个标准化的应用二进制接口ABI可为现有的所有操作系统、语言与平台所支持。它无需运行时也不需要其他额外内容。这意味着你使用C所编写的代码并非仅仅可由C代码中的调用者所调用还可以由现有的所有库、语言与环境所调用”。 Katz也认为C有“很多瑕疵” 没有范围检查不小心就会导致内存出现问题、存在野指针与内存/资源泄露情况、对并发的附加支持、没有模块、没有命名空间。错误处理非常麻烦且冗长。很容易就会搞出一堆错误调用堆栈也找不到了恶意输入会控制你的进程。闭包哈哈 Katz对C的强烈偏爱源自突破Couchbase性能极限的需求以及调试问题问题是C插件与Erlang VM联合使用所导致的。他并不认为C、Go或是D能够替换C但他认为Rust可能会成为“梦想之语言”只要它能实现“类似于C的性能而且能够做到与Erlang安全的并发和内建的健壮性”。 Katz的帖子在Reddit与Hacker News上可谓是一石激起千层浪有很多开发者谈到了C的优点也有人建议其他语言。robinei加入到了字符串操作与错误检测激战当中 我总想回到C从C等语言中当我真的这么做了时我发现不少地方通常都是很简单的感觉真棒 但接下来我需要进行字符串操作或是这类笨拙的方法。 这时会出现很多分配操作每一个都需要一个显式的free搞得我太痛苦了。我尝试通过arena allocators树来解决这个问题就像Go中的slice-strings但最终C还是缺乏一些语法工具命名空间前缀函数这导致结果变得非常笨拙将一切都分配到arenas中也是非常痛苦的。 我发现由于要进行显式的错误检测源代码文件长度增加了一倍这种情况不常发生但在诸如sqlite等一些库中任何操作都有可能失败。 还有很多方面导致我精疲力竭我觉得非常不满意。 综上所述我从哪儿来的还是回哪儿去吧通常是C。 madhadron提出了“更加现实的C” C能够在PDP-11上很直接地编译成快速的机器码。 C的标准库就是个笑话。它的缺点特别是字符串相关的处理是过去40年众多安全漏洞的罪魁祸首。 C的工具根本不值得吹嘘特别是与同辈的Smalltalk和Lisp相比。人们所使用的大多数C调试器都是命令行。根本没法和Squeak或是Allegro Common Lisp的标准调试器相比。 声明快速的C构建/调试/运行周期令人沮丧。表面上看起来很快因为C在这个领域是失败的。如果你想知道如何加快构建/调试/运行周期那么请看看Turbo Pascal吧。 你可以通过标准ABI在所有Unix上调用C虽然这么说没错但原因却是因为C的普遍存在性而已。 geophile对上述内容持不同看法 C/C/Java这是程序员视角的石头/剪刀/布。 多年以前我从C开始我发现自己用宏和库为声明与函数提供了很多很有用的组合。我发明了对象同时也发现了C。 长久以来我一直是个快乐的C用户很早就开始了还是cfront时代。但我被语言的复杂性搞崩溃了特别是特性之间微妙的交互我厌倦了内存管理渴望Java而它又适时地出现了。 我很开心。在学习语言时我肯定我漏掉了某些东西。每个对象都在堆中么真是如此么真的没有办法将一个对象在物理上嵌入到另一个对象中么但其他一切都很棒我不介意这一点。 现在我在编写一些系统这些系统会占用很多内存包含成千上万的对象有些对象很小有些则很大。每个对象的代价快要搞死我了。GC调优是个梦魇我正在实现子分配模式。我编写了微基准比较普通对象与序列化为字节数组的对象。由于C已经变得太恐怖了比令我焦头烂额的早期版本还要复杂因此我又渴望C了。 现在的我不再喜欢任何语言了。 对于某些人来说C看起来瑕疵太多已经不适应现代的生产力要求了但还有不少人依然能够很好地使用C尽管它有很多怪癖。开发者社区还是应该避免语言之争而是更好地权衡每一种语言根据项目需求与自身技能选择最合适的语言。毕竟没有一种语言是完美的。 此文在InfoQ英文站也引来了众多读者的讨论下面摘取部分读者的评论供大家参考。 读者Mark Peskin说到 嗯我喜欢C。它很简单没有C那些庞大且有瑕疵的面向对象特性。然而使用C编写大型、可扩展、模块化的企业应用需要大量规则这些规则在大型的软件企业中几乎是无法维护的。我认为C的一个问题是它会引诱聪明的开发者编写高度优化的代码充满了memcpy()与指针运算以此“打败编译器”这对于其他开发者来说几乎无法理解如果不信你去读读BSD内核代码吧。 总的来说如果有很多开发者在开发大型、复杂且长期的项目那么我认为你最好使用Java或是Scala等语言。将C用在那些偶尔出现的场景中吧这时你可能真的需要本地代码使用基于消息的系统将二者集成起来JNI不行。C还是算了吧。 读者Josh Long说到 回应Katz关于C的问题。 我同意Mark的观点在某种程度上也认可Damien的看法。 Damien提到的一点是我们很少在C中看到真正大型、全面的框架比如APIs。如果构建小型、某个方面的API通过一些typedefs/structs与函数作为“契约”那么我们可以很轻松地将库“导出”并重用。我觉得这是C最适合之处。我从来不会因为性能问题而使用C但使用C实现某些功能则是更为轻松的事情内核编程、嵌入式编程、处理硬件、所依赖的APIs并未在更高层次的语言如Java、Ruby、Python等进行过抽象的功能。 我还尽量不使用C编写具有完整功能的系统只是因为它对于大型项目来说不具备“可伸缩性”。使用C编写的大型项目最终的结果都是重新编写了很多东西比如说对象与命名空间等。恕我直言真的没有多少领域需要从头到尾都用C不可。当然了一些例外是系统级组件比如说操作系统Linux或是UI如GNOME。但对于应用来说使用更高层次的语言在高层次语言与平台之间存在缝隙之处再使用低层次APIs进行集成是更容易的做法。Java存在很多这类“缝隙”但随着APIs逐步成为很多不同操作系统上的常客后在过去10年间有些已经被逐步解决了事件驱动的IO、文件系统通知、文件权限与元数据等等。 Mark为集成C库与模块提出了很好的解决方案。他认为JNI不行建议使用消息。我是消息的忠实粉丝。本质来说成功使用消息与成功使用JNI都需要同样的东西你需要彻底简化导出API。 在使用JNI时绝不要将任何复杂的C类型“泄漏”到我的Java API中反之亦然并且总是通过数值类型与char* - jstrings进行通信。即便我所公开的本地代码是用C编写的我也依然会使用C风格的JNI而不是C因为这种规范化有利于互操作。如果保持C API表面的简洁性并且避免线程那么通过Java JNI、CPython或是MRI Ruby等可以将其作为本地扩展。 一旦完成了这个过程接下来通过消息公开C API就变得很简单了因为根据定义两个系统之间的消息负载不可能比C库还要复杂。当然了如果使用消息这意味着要么使用C编写消息代码要么将C库公开到更高层的语言上并在那里实现消息。消息好的一面是能够将高层语言代码与C代码进行隔离这么做会比Java代码要薄一些。我依然不会直接将使用C APIs编写的代码链接到我的应用中。如果C代码挂掉了那么消息系统就会接收请求直到运行着C代码的另一个节点能够进行处理为止。另一方面如果真的因为性能原因而使用C那么消息至少会引入一个网络传输更不必说系统中的另一个组件了这么做就抵消了使用C编码所带来的优势了。在这种情况下我们可以编写稳定、行为良好的JNI或是本地扩展但还是需要保持表面的小巧并且理解前置与后置条件才行。没有线程。不要在C与Java之间传递指向复杂对象的指针。请确保你自己清楚谁来负责清理内存什么时候清理。 总而言之忘掉C吧。 读者Bernd Kolb说到 或许你想要看看mbeddrmbeddr.com。 mbeddr旨在更好地支持嵌入式软件开发但并不仅仅限于此针对基于C语言与IDE的可扩展版本的小型与大型系统。现有扩展包括前置和后置的接口、组件、状态机与物理单元以及对需求追踪和产品线变化的支持。基于这些抽象mbeddr还支持基于模型检测与SMT处理的形式验证。 通过这种方式在大型项目与团队中C也可以做到“可伸缩”。此外我们还可以引入现代的编程规则。通过扩展mbeddr你甚至可以为消息等添加基础信息。 查看英文原文Is C Still A Suitable Language Today?
