为什么如此多的网络语言是解释型的而不是编译型的？
为什么 C 等语言最终没有被用于 Web 开发？ 编译速度的提高对于重负载站点肯定有用吗？
Why didn't languages such as C end up being using for web dev? Surely the speed increases from being compiled would be useful for heavy load sites?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（15）
另一个很好的理由是，在大型服务器上，执行速度并不像连接速度那么重要。 大部分时间都花在发送和接收数据上，而不是数字运算上。 实际上，在某些执行大量计算的 Web 服务中，硬处理可能作为编译程序运行。
另外，解释性语言不需要编译（在大型项目中可能需要时间），因此它更适合典型的 Web 解决方案的敏捷开发。
Another good reason is that on a big server execution speed is not so much an issue as the connection speed anyway. Most of the time is spent sending and receiving data, not number crunching. And actually in certain web services which do a lot of computations, the hard crunching is probably run as a compiled program.
Plus interpreted languages don't need compiling (which on a large project can take time), thus it's more suited for the typically agile development of web solutions.
大多数 Web 应用程序都与数据库通信。 这些应用程序中的绝大多数几乎将所有时间都花在与数据库通信上。 因此，对于应用程序的任何给定请求，应用程序服务器中都会进行少量处理，然后在等待数据库时会出现长时间的暂停。 由于任何请求的时间只有一小部分花在实际的应用程序服务器代码上，因此通过用 C/C++ 编写代码来优化该代码只会在响应时间上获得微小的、可能不明显的改进。
因此，与其专注于 C/C++ 并节省每个 CPU 周期，不如担心开发人员的生产力更有意义。 开发商的成本非常高。 而且，它们使用脚本语言甚至 Java 的效率通常比使用 C/C++ 的效率高得多。
当然，也有例外。 如果应用程序的某些请求是 CPU 或内存密集型的，则应使用 C/C++ 编写它们。 但是，对于应用程序的其余部分，最好集中精力优化算法、数据结构、与数据库的通信以及开发人员的工作效率，而不是优化语言。
Most web applications talk to a database. The overwhelming majority of these apps spend almost all of their time communicating with the database. So, for any given request to the application, there is a tiny amount of processing in the application server and then a long pause while waiting for the database. Since such a small percentage of any request's time is spent in actual application server code, optimizing that code by writing it in C/C++ will gain only a tiny, likely not noticeable, improvement in response time.
So, rather than focusing on C/C++ and saving every last CPU cycle, it makes more sense to worry about developer productivity. Developers are very expensive. And, they're typically much more productive in a scripting language or even in Java than they are in C/C++.
Of course, there are exceptions to this. And if some requests to your application are CPU or memory intensive, they should be written in C/C++. But, for the rest of your application, you're better off focusing on optimizing your algorithms, data structures, communication with the database, and developer productivity than in optimizing your language.
与 C 相比，脚本语言具有以下优点：
Scripting languages have the following advantages over C:
C 很早就用于 Web 应用程序 - 我用它编写了各种 CGI 脚本。
然而，随着时间的推移，更高效的语言（例如 C# 和 Java，当然，但不限于这些语言）已被证明对于 Web 应用程序来说“足够高效”。 请注意，C# 和 Java 都被编译为中间代码，然后进行 JIT 编译，从而实现“大致”本机代码性能。 为什么我们要使用 C 来代替？
据我所知，即使是传统的“真正解释型”语言（例如 PHP）现在也经常在执行时进行编译。 （尤其是我对 PHP 的了解都是二手的。也许它总是被编译的......同样，我确信有些 Web 平台仍然总是被解释。）
C was used for web applications early on - I wrote various CGI scripts in it.
Over time, however, more productive languages (C# and Java for example - but not exclusively those, of course) have proven to be "efficient enough" for web applications. Note that both C# and Java are compiled to intermediate code and then JIT-compiled, achieving "roughly" native code performance. Why would we want to use C instead?
Even the traditionally "genuinely interpreted" languages such as PHP are often compiled at execution time these days, as far as I'm aware. (My knowledge of PHP in particular is all second hand. Maybe it's always been compiled... And likewise I'm sure there are web platforms which are still always interpreted.)
至少最初，后端代码（我认为这就是您正在谈论的内容）完成的许多工作都是面向文本的。 他们要么直接从头开始构建页面，要么通过将数据库中的数据与模板相结合来构建页面。
C 并不......总是非常适合文本处理。 C 字符串非常基础，虽然 C 中的文本处理当然可以快速执行，但与可以帮助您更多的语言相比，它通常需要更长的时间来开发，并且需要更深入的技能才能正确完成。
At least initially, a lot of the work done by backend code (which I assume is what you're talking about) was text-oriented. They either built pages directly from scratch, or by e.g. combining data from a database with a template.
C is not ... always well-suited for text processing. C strings are very basic, and while text processing in C of course can execute fast, it often takes a bit longer to develop, and requires somewhat deeper skills to get right, than languages that help you out a bit more.
很好的问题。 原因主要是由于网络的发展。 分步骤思考：
1）“网络”上的基本文本 -> 2) 添加到文本中的一些“标记”-> 3）“center”标签和“marquee”形成！ 什么进展！！！ -> 4）在客户端编写脚本！！！ 5）-> 嗯...在服务器上编写脚本！！！
虽然我的这个答案有点愚蠢，但它确实是真的。 互联网，尤其是“网络”，是一个令人惊奇的进化过程。 事实上，对更强大的语言（以及更高性能的语言）的要求只是最近才出现的事情。
另外，看看工具。 我在记事本（和其他一些简单的应用程序）中编写了 PHP。 当我第一次进行 Web 开发时，我的计算机没有足够的硬盘空间来支持 Visual Studio 2008 :)
侧点但是：已经存在“.exe”应用程序（我认为“SunBiz" 发布到“exe”），以及一些编译的 cgi 应用程序一段时间，但数量要少得多。
Great question. The reason is basically due to the evolution of the web. Think about it in steps:
1) Basic text on the 'net' -> 2) Some 'markup' added to text -> 3) the "center" tag and "marquee" are formed!!! what progress!!! -> 4) scripting on the client!!! 5) -> hmm... scripting on the server!!!
While I formed this answer to be a bit goofy, it's really true. The interenet, and most especially the "web", has been an amazing evolutionary process. Really, requirements for more powerful languages (and more performant languages) has only been a more recent thing.
Also, look at the tools. I did my PHP in notepad (and some other simple apps). When I was first doing web development, my computer didn't have enough harddrive space to support Visual Studio 2008 :)
Side Point However: There have been ".exe" apps out there (I think "SunBiz" posts to an 'exe'), and some compiled cgi apps for a while, but they were much fewer.
值得指出的是，大多数脚本语言（Python、Ruby 等）都可以轻松（几乎微不足道）地桥接到 C。（我刚刚为 Python 程序编写了一些 C 扩展，它的简单性给我留下了深刻的印象。）如果网站/Web 应用程序确实由于使用“慢速”脚本语言而存在一些瓶颈，通常可以使用更快的语言（如 C）编写性能关键部分。事实上，这就是 Google 搜索、Facebook 等大型应用程序的原因等等——他们用脚本语言编写界面，并用 C 等其他语言完成繁重的工作。
It's worth pointing out that most scripting languages (Python, Ruby, etc.) bridge easily -- almost trivially -- to C. (I just wrote some C extensions for a Python program, and I was impressed with how easy it was.) If a website/web application does have some bottlenecks due to the use of a "slow" scripting language, one can usually write the performance-critical sections in a faster language like C. In fact, that's what large applications like Google search, Facebook, etc., do -- they write the interface in a scripting language and do the heavy lifting with other languages like C.
这主要是因为即时更改它们既快速又简单。 编译型语言需要一个与服务器相匹配的开发环境。 通过脚本，您可以使用 ftp 工具直接编辑文本，然后保存。 这种从任何操作系统或类型的任何计算机上执行此操作的能力多次挽救了我的生命（或者正确地说是我的网站生命）。
It is mostly because it is quick and simple to change them on the fly. Compiled languages require a development environment that must match the server. With a script you can use an ftp tool and edit the text directly and then save it. This ability to do this from any computer of any OS or type has save my life (or correctly my websites life) many times.
尝试用 C 和 Perl/PHP 进行一些字符串解析/操作，你就会知道。
顺便提一句：
为什么这么多人说性能不再是问题？ 对于小型主页/博客来说，我可能不是问题，但大型 Web 应用程序仍然需要调整性能（CPU/网络/内存），无论它们是用 java、php 还是 ruby 编写的。
Try to do some string parsing/manipulation in C an in Perl/PHP and you will know.
BTW:
Why do so many people state that performance is not an issue anymore? I might not be an issue for small homepages/blogs, but large scale web applications still need to be tuned for performance (cpu/network/memory) no matter if they are written in java, php or ruby.
哦，非常非常真实。 如果使用更动态的语言可以缩短开发人员一周的时间，那么您无需支付的那一周的程序员时间将为您购买一台额外的服务器。 如果您喜欢大量便宜的服务器而不是一些巨大的野兽，甚至可能是多个服务器。
对于世界上的大多数国家（即，不是 Google/Amazon/eBay/等）来说，一台额外的服务器足以弥补因语言选择而可能导致的任何原始性能损失。
Oh, so very, very true. If the use of a more dynamic language shaves a developer-week off the schedule, that week of programmer time that you don't have to pay for will buy you an additional server. Maybe even multiple servers, if you like lots of cheap ones instead of a few massive beasts.
For most of the world (i.e., not Google/Amazon/eBay/etc.), one extra server will more than compensate for any loss of raw performance that may result from the language choice.
以下是我对这个问题的看法：
Here are my thoughts on the issue:
动态语言的许多非常有用的功能，例如内省和 eval() 等函数真的很困难/不可能吗？ 以编译为本机代码的语言来实现。
话虽这么说，大多数“脚本”语言都会（即时）编译为某种中间代码，然后进行解释（Python、Ruby、Perl），甚至可能 JIT 编译为本机代码（JSP、.NET）
A lot of the extremely useful features of dynamic languages, such as introspection and functions like eval() are really difficult/impossible? to implement in languages that compile to native code.
That being said, most "scripting" languages do compile (on the fly) to some sort of intermediate code which is then interpreted (Python,Ruby,Perl) or maybe even JIT compiled to native code (JSP, .NET)
我的公司使用 C++（ISAPI 扩展）作为我们的网络应用程序。 几乎所有事情都是在编译的二进制文件中完成的。 我们还对需要脚本的系统部分使用 JavaScript 引擎（是的，服务器端 JavaScript）。 这种设计的原因是速度，但年龄也是一个因素......这是一个旧的代码库。 此外，我们将我们的产品分发给一些客户来托管自己，因此对其进行编译可以保护我们的源代码（许多解释语言可以轻松反编译，或者对于 PHP 和 Perl，根本不会编译）。
My company uses C++ (an ISAPI extension) for our webapp. Nearly everything is done in the compiled binaries. We also use a JavaScript engine for parts of the system that require scripting (yes, server-side JavaScript). The reason cited for this design is speed, but age is also a factor... this is an old codebase. Also, we distribute our product to some of our customers to host themselves, so having it compiled protects our source code (many interpreted languages are trivially decompilable, or in the case of PHP and Perl, never compiled at all).
因为业界普遍存在一种错觉，认为执行速度并不重要（正如公认的答案所证明的那样）。
我认为真正的原因是，如果您使用现有的框架，解释性语言会更容易上手，并且它们使 Web 应用程序的工作显得轻松有趣。
在很多很多情况下，您确实需要在 Web 应用程序中进行数字运算，但开发人员最终要么不执行这些操作（因为它们很昂贵）和/或将任务委托给外部服务器：数据库服务器或某些服务器其他服务器。
这可以从最近所谓的“微服务”架构的激增中看出。
Because the industry suffers from a mass delusion that execution speed does not matter (as demonstrated by the accepted answer).
I think the actual reason is that interpreted languages are easier to get started with if you use an existing framework and they make it seem easy and fun to work on a web application.
There are many, many cases where you do actually need to do number crunching in web applications, but developers end up either not doing them (because they are expensive) and/or delegate the task to an external server: either the database server or some other server.
This can be seen in the recent proliferation of so called "micro service" architectures.
很久以前，脚本语言是 Web 开发的唯一选择。 现在我们有其他替代方案（Java、.NET ..），所以情况并没有那么糟糕。
C 作为 Web 开发平台并不是很成功，因为很难构建可以从 Web/应用程序服务器加载和执行的模块，但用于构建动态 Web 应用程序的第一个框架之一是 Microsoft IIS 的 ISAPI 模块，主要用于用 C++ 开发并编译。
Scripting languages where the only option for web development a long time ago. Now we have other alternatives (Java, .NET ..) so situation is not so bad.
C as a platform was not very successful for web development since it's hard to build a module that could be loaded and executed from web/application server, but one of the first framework for building dynamic web application was ISAPI modules for Microsoft's IIS that where mainly developed in C++ and where compiled.