大型项目没有 PHP?为什么不?
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/385203/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
No PHP for large projects? Why not?
提问by jerebear
I've read a few posts where people have stated (not suggested, not discussed, not offered) that PHP should not be used for large projects.
我读过一些帖子,其中有人声明(不建议、不讨论、不提供)PHP 不应用于大型项目。
Being a primarily PHP developer, I ask two questions:
作为主要的 PHP 开发人员,我问两个问题:
- What defines a "large project"?
- Why not? What are the pitfalls of using PHP
- 什么定义了“大项目”?
- 为什么不?使用 PHP 的陷阱是什么
I run a small development team and I know from experience the quality construction, organization, documentation, commenting and encapsulation are our highest priority. We are able to develop great projects using our own framework and approach but still, I don't want to invest further if I'm wasting my time.
我经营着一个小型开发团队,从经验中我知道质量构建、组织、文档、评论和封装是我们的首要任务。我们能够使用我们自己的框架和方法开发伟大的项目,但如果我浪费时间,我仍然不想进一步投资。
Thoughts?
想法?
回答by nickf
I really hate it when people say flat out that PHP is a terrible language because you can write code which mixes presentation with logic, or that it lets you allow SQL injection. That's nothing at all to do with the language, that's the developer.
当人们直截了当地说 PHP 是一种糟糕的语言时,我真的很讨厌它,因为您可以编写将演示与逻辑混合在一起的代码,或者它允许您允许 SQL 注入。这与语言完全无关,这与开发人员有关。
PHP has proved itself to be highly scalable: Wikipedia is one of the largest and most popular sites on the Internet and it runs PHP. Enough said?
PHP 已证明其具有高度可扩展性:维基百科是 Internet 上最大和最受欢迎的站点之一,它运行 PHP。说够了?
There are a lot of tools/libraries out there that give you a framework to work in, making it less likely that someone will write poor, less-maintainable code: see CakePHP, Symfony, PDO, Smarty, etc etc etc.
有很多工具/库可以为您提供一个工作框架,从而减少有人编写糟糕、不易维护的代码的可能性:请参阅 CakePHP、Symfony、PDO、Smarty 等。
It has received a bad rap because it's a language which has very low barriers to entry: it's free, you can get very cheap PHP hosting, the documentation is the best there is, there's plenty of tutorials online, plus it makes a lot of things very easy (eg: open a URL and get the contents of the file: file('http://www.google.com');). This means that a lot of newbies picked it up and made a lot of very dodgy sites with it, but that's going to happen with whatever language you choose as your first.
它受到了不好的说唱,因为它是一种入门门槛很低的语言:它是免费的,你可以获得非常便宜的 PHP 托管,文档是最好的,网上有很多教程,而且它做了很多事情非常简单(例如:打开一个 URL 并获取文件的内容:)file('http://www.google.com');。这意味着很多新手都选择了它并用它制作了很多非常狡猾的网站,但是无论您选择哪种语言作为首选语言,都会发生这种情况。
Work with a solid ORM framework (there's about 30 questions on SO about which is best), and it will treat you good.
使用可靠的 ORM 框架(关于哪个是最好的,大约有 30 个问题),它会对你很好。
回答by jskulski
A lot of people who say not use it are really saying don't use PHP 4. It comes down to this
很多说不使用它的人实际上是在说不要使用 PHP 4。归结为这个
you can write good code in any language
你可以用任何语言编写好的代码
and
和
you can write bad code in any language
你可以用任何语言编写糟糕的代码
PHP can very often lend itself to becoming tangled spaghetti code libraries and make your 'application' really just a series of scripts (see Moodle for a good example of this...)
PHP 经常会变成杂乱无章的意大利面条式代码库,并使您的“应用程序”实际上只是一系列脚本(参见 Moodle 的一个很好的例子......)
I think a lot of the 'Don't use PHP for large stuff' is coming from PHP being hacked up from it's original purpose: a templating language. Which I can understand, but there are lots of projects that prove you can do it (Drupal, mediawiki, Facebook).
我认为很多“不要将 PHP 用于大的东西”是因为 PHP 被从它的原始目的:一种模板语言中窃取了出来。我能理解,但有很多项目证明你可以做到(Drupal、mediawiki、Facebook)。
回答by cletus
Theres no reason you can't use PHP for large projects. After all, Facebook is built on PHP. There will be issues however but there are issues with any large project.
没有理由不能将 PHP 用于大型项目。毕竟,Facebook 是建立在 PHP 之上的。但是会有问题,但任何大型项目都会有问题。
What makes PHP so pervasive is the low barrier to entry and cheap hosting. It runs as an Apache extension and you can pretty much just start coding. If you go to more enterprise platforms such as .Net or Java, they have a much higher barrier to entry but they also come with a lot of infrastructure to help you make applications that scale.
PHP 如此普遍的原因是入门门槛低和托管费用低。它作为 Apache 扩展运行,您几乎可以开始编码。如果您使用更多的企业平台,例如 .Net 或 Java,它们的准入门槛要高得多,但它们也带有大量基础设施,可帮助您制作可扩展的应用程序。
For example, the database abstraction in PHP is (imho) woeful. It's vendor specific. With MySQL, people tend to do things like:
例如,PHP 中的数据库抽象(恕我直言)可悲。这是特定于供应商的。使用 MySQL,人们倾向于做这样的事情:
function get_users($surname) {
mysql_query("select * from users where surname = '$surname'");
...
}
which is bad for several reasons:
这很糟糕,原因有几个:
- It makes poor use of the query cache;
- It doesn't handle escaping of characters (which, of course, can be done with
mysql_escape_string()but you'll be surprised how often people don't do this); and - It's fairly easy to code in such a way as to allow SQL injection attacks.
- 它没有充分利用查询缓存;
- 它不处理字符的转义(当然,可以这样做,
mysql_escape_string()但您会惊讶地发现人们经常不这样做);和 - 以允许 SQL 注入攻击的方式编写代码是相当容易的。
Personally I prefer mysqli for all the above reasons but it has it's own problems: namely that using LONGTEXT fields crashes mysql and has done since at least 2005 with still no fix (yes I and several others have raised a bug).
由于上述所有原因,我个人更喜欢 mysqli,但它有自己的问题:即使用 LONGTEXT 字段会使 mysql 崩溃,并且至少从 2005 年开始就已经完成了,但仍然没有修复(是的,我和其他几个人提出了一个错误)。
Compare this to Java (with which I'm more familiar) and JPA or Ibatis are vastly better ORM solutions with higher startup costs but they will help you on an enterprise scale.
将此与 Java(我更熟悉)进行比较,JPA 或 Ibatis 是更好的 ORM 解决方案,启动成本更高,但它们会在企业规模上为您提供帮助。
So you're not prohibited from doing large projects on PHP. It's simply harder in that you have to do increasingly more work yourself to replicate what other platforms provide you.
所以你不会被禁止在 PHP 上做大型项目。更难的是你必须自己做越来越多的工作来复制其他平台提供给你的东西。
That being said, PHP + memcached/APC + beanstalkd goes a long way.
话虽如此,PHP + memcached/APC + beanstalkd 走了很长一段路。
Oh that's the other problem: PHP doesn't really support background processing or threading. You need something else for that (or standalone scripts). If you're using something else, why not use that for the Web stuff too (eg Java, Ruby, .Net, etc)?
哦,这是另一个问题:PHP 并不真正支持后台处理或线程。您需要其他东西(或独立脚本)。如果您正在使用其他东西,为什么不也将其用于 Web 内容(例如 Java、Ruby、.Net 等)?
回答by Vinko Vrsalovic
As the question I linkedwas deleted, I'll place some of it here:
Question
题
I made a tongue-in-cheek comment in another question thread calling PHP a terrible language and it got down-voted like crazy. Apparently there are lots of people here who love PHP.
我在另一个问题线程中做了一个半开玩笑的评论,称 PHP 是一种糟糕的语言,但它像疯了一样被否决了。显然这里有很多人喜欢 PHP。
So I'm genuinely curious. What am I missing? What makes PHP a good language?
所以我真的很好奇。我错过了什么?是什么让 PHP 成为一门好语言?
Here are my reasons for disliking it:
以下是我不喜欢它的原因:
PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design.
PHP has inconsistent parameter ordering of built-in functions, eg array_map vs. array_filter which is annoying in the simple cases and raises all sorts of unexpected behaviour or worse.
The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.
A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!
Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!
Overly-broad implicit type conversion leads to bugs. I have no problem with implicit conversions of, say, float to integer or back again. But PHP (last I checked) will happily attempt to magically convert an array to an integer.
Poor recursion performance. Recursion is a fundamentally important tool for writing in any language; it can make complex algorithms far simpler. Poor support is inexcusable.
Functions are case insensitive. I have no idea what they were thinking on this one. A programming language is a way to specify behavior to both a computer and a reader of the code without ambiguity. Case insensitivity introduces much ambiguity.
PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.
PHP performance is abysmal without caching. Does anyone sell a commercial caching product for PHP? Oh, look, the designers of PHP do.
PHP 对内置函数和库函数的命名不一致。可预测的命名模式在任何设计中都很重要。
PHP 内置函数的参数顺序不一致,例如 array_map 与 array_filter,这在简单情况下很烦人,并引发各种意外行为或更糟。
PHP 开发人员不断反对内置函数和较低级别的功能。一个很好的例子是他们弃用了函数的引用传递。这对任何人来说都是一场噩梦,比如函数回调。
重新设计时缺乏考虑。上述弃用消除了在许多情况下为函数提供默认关键字值的能力。他们在 PHP 5 中修复了这个问题,但他们在 PHP 4 中弃用了传递引用!
名称空间执行不佳(以前根本没有名称空间)。既然命名空间已经存在,那么我们使用什么作为解引用字符呢?反斜杠!普遍用于转义的字符,即使在 PHP 中!
过于宽泛的隐式类型转换会导致错误。我对隐式转换没有问题,比如浮点到整数或再次返回。但是 PHP(最后我检查过)会很乐意尝试神奇地将数组转换为整数。
递归性能差。递归是任何语言写作的基本重要工具;它可以使复杂的算法简单得多。糟糕的支持是不可原谅的。
函数不区分大小写。我不知道他们是怎么想的。编程语言是一种向计算机和代码阅读者明确指定行为的方式。不区分大小写会导致很多歧义。
PHP 鼓励(实际上需要)将处理与表示相结合。是的,您可以编写不这样做的 PHP,但实际上以不正确的方式(从合理的设计角度)编写代码更容易。
如果没有缓存,PHP 的性能非常糟糕。有人卖 PHP 的商业缓存产品吗?哦,看,PHP 的设计者是这样做的。
Worst of all, PHP convinces people that designing web applications is easy. And it does indeed make much of the effort involved much easier. But the fact is, designing a web application that is both secure and efficient is a very difficult task.
最糟糕的是,PHP 使人们相信设计 Web 应用程序很容易。它确实使所涉及的大部分工作变得更加容易。但事实是,设计一个既安全又高效的 Web 应用程序是一项非常艰巨的任务。
By convincing so many to take up programming, PHP has taught an entire subgroup of programmers bad habits and bad design. It's given them access to capabilities that they lack the understanding to use safely. This has led to PHP's reputation as being insecure.
通过说服如此多的人开始编程,PHP 教会了整个程序员子群的不良习惯和不良设计。它使他们能够访问他们缺乏安全使用的理解的功能。这导致了 PHP 不安全的声誉。
(However, I will readily admit that PHP is no more or less secure than any other web programming language.)
(不过,我很乐意承认 PHP 并不比任何其他 Web 编程语言更安全。)
What is it that I'm missing about PHP? I'm seeing an organically-grown, poorly-managed mess of a language that's spawning poor programmers.
我对 PHP 的遗漏是什么?我看到一门有机生长、管理不善的语言混乱正在催生糟糕的程序员。
So convince me otherwise!
所以说服我否则!
Top Rated Answer
评分最高的答案
I'll take a stab at responding to each of your bullet points
我会尽量回复你的每一个要点
PHP has inconsistent naming of built-in and library functions. Predictable naming patterns are important in any design.
PHP 对内置函数和库函数的命名不一致。可预测的命名模式在任何设计中都很重要。
I both love and hate this topic. Because at its core, this issue is correct. Why are some bi-word function split with an underscore, and some aren't? Why do needle and haystack parameters swap positions in the argument signature sometimes? It's ridiculous. But at the end of the day... does this really matter? My IDE with intellisense and php.net just a browser click away, this is just plain not that big of a deal. Is it a negative against PHP as a language? Yes. Does it hinder my ability to be an effective programmer? No.
我又爱又恨这个话题。因为从本质上讲,这个问题是正确的。为什么有些双字函数用下划线分割,有些则不是?为什么needle 和haystack 参数有时会在参数签名中交换位置?这很荒谬。但归根结底……这真的很重要吗?我的带有智能感知和 php.net 的 IDE 只需点击浏览器即可,这很简单,没什么大不了的。对 PHP 作为一种语言是否不利?是的。它会阻碍我成为一名高效程序员的能力吗?不。
The PHP developers constantly deprecate built-in functions and lower-level functionality. A good example is when they deprecated pass-by-reference for functions. This created a nightmare for anyone doing, say, function callbacks.
PHP 开发人员不断反对内置函数和较低级别的功能。一个很好的例子是他们弃用了函数的引用传递。这对任何人来说都是一场噩梦,比如函数回调。
Personally, I think this is not a good point. Deprecation is necessary to the evolution of a language, especially one that has as much kruft as PHP does. PHP gets a lot of flak for "making it easy to be a bad programmer*" but at the same time, the PHP group also gets in trouble when they try to remove stupid constructs from the language, such as call-time pass-by-reference. Eliminating call-time pass-by-reference was one of the best moves they ever made. There was no easier way for a novice developer to shoot themselves in the foot than with this "feature".
就个人而言,我认为这不是一个好点。弃用对于一门语言的发展来说是必要的,尤其是像 PHP 一样有很多 kruft 的语言。PHP 因“很容易成为一个糟糕的程序员*”而受到很多批评,但与此同时,当 PHP 小组试图从语言中删除愚蠢的结构时,例如调用时传递,也会遇到麻烦-参考。消除呼叫时间传递引用是他们做过的最好的举措之一。对于新手开发人员来说,没有比使用这个“功能”更容易的方法了。
A lack of consideration in redesign. The above deprecation eliminated the ability to, in many cases, provide default keyword values for functions. They fixed this in PHP 5, but they deprecated the pass-by-reference in PHP 4!
重新设计时缺乏考虑。上述弃用消除了在许多情况下为函数提供默认关键字值的能力。他们在 PHP 5 中修复了这个问题,但他们在 PHP 4 中弃用了传递引用!
I don't think there's a general lack of consideration at all, I think you just got stung by this particular change and have been left with a sour taste in your mouth. Language changes are often known months if not years ahead of time. A migration guide was provided for the move from 4 to 5, and the version differences are documented in the manual. Call-time pass-by-reference was a horrible "feature" and doesn't give the developer any expressive power they can't get by other means. I'm glad it is gone (along with other crap like magic quotes)
我认为根本没有普遍缺乏考虑,我认为你只是被这个特殊的变化刺痛了,嘴里留下了酸味。语言变化通常可以提前数月甚至数年得知。为从 4 到 5 的迁移提供了迁移指南,手册中记录了版本差异。调用时传递引用是一个可怕的“功能”,并没有给开发人员任何他们无法通过其他方式获得的表达能力。我很高兴它消失了(以及其他废话,如魔术报价)
Poor execution of name spaces (formerly no name spaces at all). Now that name spaces exist, what do we use as the dereference character? Backslash! The character used universally for escaping, even in PHP!
名称空间执行不佳(以前根本没有名称空间)。既然命名空间已经存在,那么我们使用什么作为解引用字符呢?反斜杠!普遍用于转义的字符,即使在 PHP 中!
I have mixed feelings about this. Part of me thinks "who cares, character escaping has no meaning outside of a string anyway", and part of me thinks "surely they could use something better". But could they? I don't know, I'm not a developer for the Zend parser. Is it a huge oversight that until 5.3 PHP never had namespaces at all? Yes, absolutely.
对此我五味杂陈。我的一部分认为“谁在乎,无论如何,字符转义在字符串之外没有任何意义”,而我的一部分认为“他们肯定可以使用更好的东西”。但是他们可以吗?我不知道,我不是 Zend 解析器的开发人员。在 PHP 5.3 之前根本没有名称空间,这是一个巨大的疏忽吗?是的,一点没错。
Overly-broad implicit type conversion leads to bugs. I have no problem with implicit conversions of, say, float to integer or back again. But PHP (last I checked) will happily attempt to magically convert an array to an integer.
过于宽泛的隐式类型转换会导致错误。我对隐式转换没有问题,比如浮点到整数或再次返回。但是 PHP(最后我检查过)会很乐意尝试神奇地将数组转换为整数。
I think it's ok to disagree with how PHP does this, but disagree that it makes the language "bad". But ask me how much I want to sit in this topic and argue about weak vs strong typing. (P.S. I don't, at all) For the record: PHP will issue an E_WARNING level error when the type of an argument matters and cannot by solved by coercion.
我认为不同意 PHP 如何做到这一点是可以的,但不同意它使语言变得“糟糕”。但是问我我有多想在这个话题上讨论弱打字和强打字。(PS我不这样做,在所有)对于记录:当一个参数的问题的类型和无法通过强制解决PHP将发出E_WARNING级别的错误。
Poor recursion performance. Recursion is a fundamentally important tool for writing in any language; it can make complex algorithms far simpler. Poor support is inexcusable.
递归性能差。递归是任何语言写作的基本重要工具;它可以使复杂的算法简单得多。糟糕的支持是不可原谅的。
PHP is a DSL for the web. I've been doing it full-time for 8 years and have maybe used recursion 4 or 5 times, usually for some type of annoying directory or XML traversal. It's just not a pattern that is needed for web development that often. I'm not excusing the slow performance, but this is an academic issue far more than it is a production issue. If you need really powerful recursive performance, PHP is already the wrong language for you.
PHP 是一种用于网络的 DSL。我已经全职工作了 8 年,可能已经使用了 4 或 5 次递归,通常用于某种令人讨厌的目录或 XML 遍历。这不是 Web 开发经常需要的模式。我不是在为缓慢的性能找借口,但这是一个学术问题,而不是生产问题。如果您需要真正强大的递归性能,PHP 对您来说已经是错误的语言。
Functions are case insensitive. I have no idea what they were thinking on this one. A programming language is a way to specify behavior to both a computer and a reader of the code without ambiguity. Case insensitivity introduces much ambiguity.
函数不区分大小写。我不知道他们是怎么想的。编程语言是一种向计算机和代码阅读者明确指定行为的方式。不区分大小写会导致很多歧义。
I totally 100% agree with this.
我完全 100% 同意这一点。
PHP encourages (practically requires) a coupling of processing with presentation. Yes, you can write PHP that doesn't do so, but it's actually easier to write code in the incorrect (from a sound design perspective) manner.
PHP 鼓励(实际上需要)将处理与表示相结合。是的,您可以编写不这样做的 PHP,但实际上以不正确的方式(从合理的设计角度)编写代码更容易。
*Hmmm, this topic sounds desperately familiar...
*嗯,这个话题听起来非常熟悉......
But seriously, I find it remarkable that people will complain about a language that will absolutely 100% let you implement any output system you want (the sheer volume and style of PHP templating systems alone speaks to this) - OR - skip all that overhead and just output directly. This does not make PHP bad at all. It's part of what makes PHP good.
但是说真的,我发现人们会抱怨一种语言绝对可以 100% 地让你实现你想要的任何输出系统(仅 PHP 模板系统的庞大数量和风格就说明了这一点)——或者——跳过所有这些开销和直接输出就好了 这根本不会使 PHP 变得糟糕。这是使 PHP 变得优秀的部分原因。
PHP performance is abysmal without caching. Does anyone sell a commercial caching product for PHP? Oh, look, the designers of PHP do.
如果没有缓存,PHP 的性能非常糟糕。有人卖 PHP 的商业缓存产品吗?哦,看,PHP 的设计者是这样做的。
Do you mean bytecode caching (like an accelerator), or output caching?
您是指字节码缓存(如加速器)还是输出缓存?
If the former, then I don't really know how much I care about this topic. Accelerators are free and easy to run. We could argue about why it isn't part of the language but in the end, I don't think it matters much.
如果是前者,那么我真的不知道我有多在意这个话题。加速器是免费且易于运行的。我们可以争论为什么它不是语言的一部分,但最终,我认为这并不重要。
If you are talking about output caching then I don't know what to say to you. ANY web project with significant traffic needs caching (seed podcast #27, for example). This is not a PHP-specific issue at all.
如果您在谈论输出缓存,那么我不知道该对您说什么。任何具有大量流量的 Web 项目都需要缓存(例如,种子播客 #27)。这不是一个PHP特定的问题,在所有。
In summary, I think you consider PHP a "bad" language in a very academic fashion. And in your previous post you were probably voted down by people like me who use PHP to "get things done".
总之,我认为您认为 PHP 是一种非常学术化的“糟糕”语言。在您之前的帖子中,您可能被像我这样使用 PHP 来“完成任务”的人投票否决了。
Second Top Rated Answer
第二个评分最高的答案
All your criticisms (and some more) are valid. You are allowed and even expected to hate PHP.
你所有的批评(以及更多)都是有效的。你被允许甚至被期望讨厌 PHP。
But, then again, it has some benefits:
但是,话又说回来,它有一些好处:
- Ubiquitous
- Fast (especially using opcode caches)
- Huge community (and great documentation)
- Works
- 无处不在
- 快速(尤其是使用操作码缓存)
- 庞大的社区(和很棒的文档)
- 作品
Finally, you can overcome many if not all the downsides by writing good code you'd write in any other language. You can write solid, secure and good smelling code in PHP, which many times will run faster and be easier to host and to scale than many alternatives.
最后,您可以通过编写用任何其他语言编写的良好代码来克服许多(如果不是全部)缺点。您可以在 PHP 中编写可靠、安全和良好的代码,与许多替代方案相比,PHP 运行速度更快,更容易托管和扩展。
Third Top Rated Answer
第三个评分最高的答案
What is it that I'm missing about PHP? I'm seeing an organically-grown, poorly-managed mess of a language that's spawning poor programmers.
我对 PHP 的遗漏是什么?我看到一门有机生长、管理不善的语言混乱正在催生糟糕的程序员。
Simple. The fact that poor programmers get very defensive about their language. ;) PHP is easy to learn, much easier than the alternatives, and once you've learned it, it's not exactly obvious 1) what's wrong with PHP, 2) how the alternatives are better, and 3) how to switch to, and learn, one of the alternatives.
简单的。事实上,可怜的程序员对他们的语言非常防御。;) PHP 很容易学习,比替代方案容易得多,一旦你学会了它,就不是很明显 1) PHP 有什么问题,2) 替代方案如何更好,以及 3) 如何切换到,以及学习,选择之一。
And perhaps the fact that, well, what alternatives do people have? ASP? That has plenty of problems on its own, from being unable to run on the majority of webservers (Apache), to some ridiculous and overengineered design choices on its own (webforms? Viewstate? AJAX where your asynchronous" requests are intercepted and run sequentially?) Ruby on Rails? Well, perhaps, except how many webservers support it again? It's not exactly easily approachable at the moment. And it's slow. So perhaps PHP's "strength" is really that no goodalternative exists. At least this is why I stay away from all web programming when at all possible. PHP sucks, and I'm not too keen on any of the alternatives either.
也许事实上,人们有什么选择?ASP?这本身就有很多问题,从无法在大多数网络服务器 (Apache) 上运行,到一些荒谬和过度设计的设计选择(网络表单?Viewstate?AJAX,其中您的异步“请求被拦截并按顺序运行? ) Ruby on Rails?嗯,也许,除了有多少网络服务器再次支持它?目前还不是很容易接近。而且速度很慢。所以也许 PHP 的“力量”真的是没有好的替代品存在。至少这就是为什么我尽可能远离所有 Web 编程。PHP 很烂,而且我也不太热衷于任何替代方案。
PHP has so many fundamental problems that it's not even funny. From the lack of unicode support, to the many implicit type conversions which often lead to unexpected security holes, to the complete mixing of presentation and... everything else, or to the default database module which doesn't (last I checked) use parametrized queries. We're talking about a language made for two things, database access and generating HTML, and which is terrible at both.
PHP 有很多基本问题,甚至都不好笑。从缺乏 unicode 支持,到经常导致意外安全漏洞的许多隐式类型转换,到完全混合表示和...参数化查询。我们谈论的是一种为两件事而生的语言,数据库访问和生成 HTML,这两者都很糟糕。
It's just a nasty mess, a language designed by people who aren't qualified, or able, to design a language. ;)
它只是一团糟,一种由没有资格或能力设计语言的人设计的语言。;)
回答by frankodwyer
For me the worst PHP sin is coupling of presentation with business logic. It's not that you can't write it in a better way, but it doesn't encourage you to, and if anything it encourages you not to.
对我来说,最糟糕的 PHP 罪是将表示与业务逻辑结合起来。并不是说你不能以更好的方式写它,而是它不鼓励你,如果有的话,它鼓励你不要。
A large number of security vulnerabilities are associated with PHP sites, too. I can't prove it is disproportionate (after all a lot of sites are written in PHP), but I suspect it is. If I'm right, then since security vulnerabilities are a class of bug, I suspect PHP sites tend to be more buggy on the whole also.
大量安全漏洞也与 PHP 站点相关。我无法证明它不成比例(毕竟很多网站都是用 PHP 编写的),但我怀疑它是。如果我是对的,那么由于安全漏洞是一类错误,我怀疑 PHP 站点总体上也往往有更多错误。
(I don't think that pointing at a few large sites and saying they managed to do it in PHP is any argument against this, by the way. It's a bit like saying that cigarettes don't cause cancer because your next door neighbour smoked and lived to be 100.)
(顺便说一句,我不认为指着几个大网站并说他们设法用 PHP 做到这一点是反对这一点的任何论据。这有点像说香烟不会致癌,因为你的隔壁邻居吸烟并活到 100 岁。)
回答by Eran Galperin
Check out this similar question - Can PHP handle enterprise level sites as well as Java
看看这个类似的问题 - PHP 可以处理企业级站点以及 Java
Recapping - Facebook, Wikipedia, Yahoo.com, Digg, Flickr and many other giant sites are running on PHP. If you ever come close to making something of that caliber, you can still rest assured you can get there with PHP.
回顾 - Facebook、维基百科、Yahoo.com、Digg、Flickr 和许多其他大型网站都在 PHP 上运行。如果您已经接近制作出这种水准的东西,您仍然可以放心,您可以使用 PHP 实现这一目标。
How maintainable, extendable, reliable, secure and performant your applications will be is entirely up to you and is language-agnostic. In favor of PHP though, it has very convenient tools for building web applications.
您的应用程序的可维护性、可扩展性、可靠性、安全性和性能如何完全取决于您,并且与语言无关。虽然支持 PHP,但它有非常方便的工具来构建 Web 应用程序。
回答by Georgi
For me, and talking about large or even huge projects, it (primarily) boils down to one word: Dependencies.
对我来说,谈论大型甚至大型项目时,它(主要)归结为一个词:Dependencies。
The problem with a scripting language is like in every thing in the world: The greatest advantage is the greatest disadvantage at the same time.
脚本语言的问题就像世界上的每一件事一样:最大的优势同时也是最大的劣势。
The greatest advantage is to code free and fast. Just write a script and it will server it's purpose. No verbosity needed, simply code.
最大的优势是免费和快速的编码。只需编写一个脚本,它就会达到它的目的。无需冗长,只需编写代码。
The greatest disadvantage is, in a way, to check if this script is not disturbing other scripts. Or better: Change an old script others are relying on. Are you sure that all dependencies do work out as you desired?
在某种程度上,最大的缺点是检查此脚本是否不会干扰其他脚本。或者更好:更改其他人依赖的旧脚本。您确定所有依赖项都按您的意愿运行吗?
This is not true for "normal" web page generation, whatever normal means here. But we have a product relying on some 500k lines of source code, with customizations for clients consisting of an additional 100k lines of code, too. And I am deadly glad that a compiler checks all dependencies and warns/errors me in case I did something wrong (like, speaking lowest level here, misstyping a variable or method call).
这对于“正常”网页生成而言并非如此,无论这里的正常含义是什么。但是我们的产品依赖于大约 50 万行源代码,而客户的定制也包含额外的 10 万行代码。而且我非常高兴编译器检查所有依赖项并警告/错误我以防万一我做错了(例如,在这里说最低级别,错误输入变量或方法调用)。
I think this and the fact that other languages provide more simple-to-use "enterprisy" features by their nature (i.e. application servers for "bank usages") boils it down why many do not see PHP in large (or better: huge) projects.
我认为这一点以及其他语言本质上提供更易于使用的“企业”功能(即用于“银行用途”的应用程序服务器)的事实归结为为什么许多人没有看到大型 PHP(或更好:巨大)项目。
回答by JW.
Our company runs several large-ish web sites using PHP, and have had no problems that were related to the language.
我们公司使用PHP运行了几个大型网站,并且没有出现与该语言相关的问题。
回答by JW.
There's something about the construction of the PHP language that is not good enough for me. For example, the name of the functions. It is a non best practice use a several ways to name a function in one language. The mixture between underscores (function_name), words stick together (functionname), etc.I mean, this is really a mess. There are too many functions that are very similar or do the same things, but their names are so confusing. This is not characteristic of a good programming language.
PHP 语言的构建有些方面对我来说不够好。例如,函数的名称。使用多种方法以一种语言命名函数不是最佳实践。下划线(function_name),单词粘在一起(functionname)等等的混合。我的意思是,这真的是一团糟。非常相似或做相同事情的函数太多了,但它们的名字却如此混乱。这不是好的编程语言的特征。
In large deployments, the language must be enough easy and specific to write. Something that PHP omits like the declaration of variable types, become very difficult to understand and deal with later.
在大型部署中,语言必须足够容易和特定才能编写。PHP 省略的一些东西,比如变量类型的声明,在以后变得非常难以理解和处理。
Other point is the constant addition of features and canceling of some other. It supposes that the addition of OOP in PHP 5 gonna make the things easier for programmers, but what about the considerations of back compatibility?
另一点是不断添加功能并取消其他功能。它假设在 PHP 5 中添加 OOP 会让程序员更容易,但是对向后兼容性的考虑呢?
The principal reason that this programming language is like it is, is due to its origins: Personal Home Page. It was not designed for large deployments.
这种编程语言之所以如此,主要原因在于它的起源:个人主页。它不是为大型部署而设计的。
I know that there are great efforts to make this language an enterprise-weight language, and personally, I'm waiting for a good enough open source server-side programming language; but until this day comes, it's gonna run a lot of water under the bridge.
我知道要使这种语言成为企业级语言已经付出了巨大的努力,而且就我个人而言,我正在等待一种足够好的开源服务器端编程语言;但在这一天到来之前,桥下会流很多水。

