Python vs PHP

[Coldblackice]

I've found a number of different articles on the subject through Google, but curious what [H]'ers opinion of the two is.

Do you have a preference of one over the other? Why might you use one over the other?

From what I've gathered by general feel over the past year or so, it seems that PHP is much more prevalent and in demand, but that there's a lot of hype and praise for Python. This has led me to believe that Python is gaining some significant speed, although I haven't really seen it much in job listings (compared with PHP, which is basically in any/all listings).

 

[Quicksilver_]

PHP.

 

[Dogs]

On a technical level, you should be able to accomplish what you want with either one. If you hear somebody saying "PHP is a broken piece of shit" or "Python has so many major flaws" or something along those lines (and I'm sure you inevitably will, when discussing the subject), take everything they say with a grain of salt, since there aren't significant problems with either language.

Given a choice of the P languages, I generally prefer Perl over both of those, mostly just for small, syntactical preferences which I hold as well as the age, ubiquity and community of the language. But between Python and PHP, I'd go with Python over PHP simply because Python seems to have a more widespread range of common uses. While PHP is very prevalent in web applications, it's far less prevalent when doing much of anything else, whereas Python is also commonly used for system administration and all sorts of other tasks where using a scripting language is practical.

 

[robvas]

Two entirely different languages. I have used PHP in the past, use Ruby now, and I'd learn Python before starting another project with PHP.

 

[toast0]

If you don't know Perl, you should check that out, there's been a lot of work on Perl 5 lately, so it is new and vibrant (as well as old and established). Be sure to check out CPAN and perlmonks. I haven't actually read it, but you should probably check out Modern Perl, there's a lot of perl code out there that's many years old, and some of the ways people used to do things turn out to be horrible; so starting from the good ways and learning the bad ways when you need to is a better choice. (Ignore Perl6, not sure anything is going to come of that ever)

I personally despise Python's design choice that whitespace matters. Yes, this is petty, but I've got a bunch of other languages, so whatever. I do see a lot of startups invested in Python, so it does seem to be a workable language.

PHP is an excellent language for getting things done quickly on the web. This is good and bad; there's a lot of code out there in PHP that is terrible. Like with Perl, early best practices are actually crap. I don't have a good reference for this, but please please please avoid mixing of html and php by going in and out of php; it's best to just be in PHP all the time, and use echo (with heredocs for large blocks of html). Also, keep in mind that at the end of the request, everything is thrown away (mostly), so don't build up a whole lot of objects; I try to keep my php code as procedural as possible. There are also a lot of web frameworks for PHP, which is ridiculous, the whole language is a web framework. There are people who use PHP outside of the web context, those people are crazy. There are people who say PHP is a terrible language, those people are right, but it's a very effective terrible language.

So in summary, my opinion is skip Python, and learn PHP if you're doing web stuff, and Perl if you're not. If your web stuff needs offline data processing, Perl for offline, PHP for online is usually a good fit. (Although Python people tell me I could use Python for both)

 

[Quicksilver_]

PHP is an excellent language for getting things done quickly on the web. This is good and bad; there's a lot of code out there in PHP that is terrible. Like with Perl, early best practices are actually crap. I don't have a good reference for this, but please please please avoid mixing of html and php by going in and out of php; it's best to just be in PHP all the time, and use echo (with heredocs for large blocks of html). Also, keep in mind that at the end of the request, everything is thrown away (mostly), so don't build up a whole lot of objects; I try to keep my php code as procedural as possible. There are also a lot of web frameworks for PHP, which is ridiculous, the whole language is a web framework. There are people who use PHP outside of the web context, those people are crazy. There are people who say PHP is a terrible language, those people are right, but it's a very effective terrible language

D: These are the best things to do in PHP.

 

[toast0]

D: These are the best things to do in PHP.

Yeah... I thought that too... it's just super hard to follow the logic when you come back in a couple days to debug.

 

[Fort_Major]

If you're looking for a career and I'm guessing you're into "open source/open operating system/free tools" I'd recommend Ruby on Rails.

Python is often times used in more back-end uses where it doesn't often times get mentioned in a job listing or even that it got used.

Everybody and everybody's mom uses and knows PHP and I feel this makes it a poor career choice. Perhaps a quick-fix job. Depending upon what you're aiming for a PHP position salary might make you happy. It's never once made me even consider calling or submitting a resume.

Both are decent languages to learn so if you're looking at a career in this area I recommend learning both over time, not all at once.

 

[Dogs]

If you're looking for a career and I'm guessing you're into "open source/open operating system/free tools" I'd recommend Ruby on Rails.

If you're looking for a career, I'd say it's stupid to limit yourself to learning any one language anyways. In fact, I'd say it's stupid to let the languages you have learned define your skillset altogether. If your goal is to get a career, asking which language to learn is rather trivial, because there are other deeper, more important things to learn than worrying about which specific language you know. A competent professional will be able to transition from one language to another without much headache, and competent employers know this.

 

[mastaBlasta]

Everybody and everybody's mom uses and knows PHP and I feel this makes it a poor career choice. Perhaps a quick-fix job. Depending upon what you're aiming for a PHP position salary might make you happy. It's never once made me even consider calling or submitting a resume.
.

People learn how to code a few simple server-side functions and call themselves PHP experts. Same with Javascript, where if you can do a jQuery click event, you're pretty much a pro. People think that that's all there is to the language but in fact very few can write robust, secure, fast, scalable PHP applications.

Majority of PHP code out there is terrible precisely because of that. Because people have a low regard for the language and refuse to spend time learning proper style.

 

[wyqtor]

Clojure and Racket are far more powerful than both, in skilled hands.

 

[Pepster64]

Right now I am learning PHP (I eventually learn Ruby on Rails), but I have learn JQuery (Still am), Actionscript and a littlebit of JavaScript. Though I would recommend JQuery for it's basically just an off-shoot of JavaScript, there's a technical word for it - but it escapes me for moment. I'm pretty deep into learning PHP (I'm basically using it to create a small CMS scripts for my website). A couple of recommendations on PHP, first when writing PHP code, get the PHP code working first for you can easily add the HTML code in later either as echoing or using HTML/CSS tags (I personally don't mind mixing HTML/PHP, but I keep it logically separated on my page.) Secondly, don't pay any attention to tutorials using mysql, learn mysqli or PDO (If you do follow mysql tutorials learn how to convert to the others). If you go the mysqli route make sure you use prepare statements otherwise you are just defeating its purpose. That's my opinion. Learning as many languages as possible is better that being hamstring to one when it comes to job opportunities.

 

[int]

Though I would recommend JQuery for it's basically just an off-shoot of JavaScript, there's a technical word for it - but it escapes me for moment.

It's just a library. In no way, shape or form is it an off-shoot of JavaScript...sorry to be pedantic, but if someone picks that up and repeats it in a job interview, they're going to raise some eyebrows.

 

[krogen]

Right now I am learning PHP (I eventually learn Ruby on Rails), but I have learn JQuery (Still am), Actionscript and a littlebit of JavaScript. Though I would recommend JQuery for it's basically just an off-shoot of JavaScript, there's a technical word for it - but it escapes me for moment. I'm pretty deep into learning PHP (I'm basically using it to create a small CMS scripts for my website). A couple of recommendations on PHP, first when writing PHP code, get the PHP code working first for you can easily add the HTML code in later either as echoing or using HTML/CSS tags (I personally don't mind mixing HTML/PHP, but I keep it logically separated on my page.) Secondly, don't pay any attention to tutorials using mysql, learn mysqli or PDO (If you do follow mysql tutorials learn how to convert to the others). If you go the mysqli route make sure you use prepared statements otherwise you are just defeating its purpose. That's my opinion. Learning as many languages as possible is better that being hamstring to one when it comes to job opportunities.

jQuery is JavaScript. It's a JavaScript library primarily used for DOM manipulation. If you're learning jQuery you are also learning JavaScript. No way to separate the two.

Don't reinvent a wheel with PHP. It's pointless. Learn about programming paradigms and architectural patterns. Many frameworks use MVC. Learn it.

Mysqli is just a driver, AFAIK. Learn SQL as it's very useful to understand but don't dwindle on it. After you feel comfortable with SQL learn about abstraction layers (ORMs and the like).

Move on from PHP, eventually. It's a crude language plagued by legacy logic.

 

[Grazehell]

Mysqli is just a driver, AFAIK.

I think what he/she might be saying here is don't use mysql but mysqli. Using one instead of the other requires changing some of your functions etc.
Mysqli support transaction handling and prepared statements so to fully make use of it includes making use of these features.

 

[toast0]

Mysqli is just a driver, AFAIK. Learn SQL as it's very useful to understand but don't dwindle on it. After you feel comfortable with SQL learn about abstraction layers (ORMs and the like).

Not to start a flame war, but what I think you should learn about ORMs is that they shouldn't be used. Maybe people aren't using ORM tools correctly, but from what I've seen, they are very good at making queries that are not easy for SQL servers to run, and it's very hard to tune the queries as well. If you write all your queries by hand, and see some of your queries show in up the slow query log, it's easy to track them down, and rewrite the queries as needed; but if it's all ORM, it can be difficult to find where the query is built and how to alter the query. I am biased towards high traffic sites because of my experience, but if I'm going to have to hand optimize my SQL once I get to be high traffic, and I intend to be high traffic, I might as well start with hand written SQL.

But yes, definitely use PDO or mysqli instead of mysql if you're starting fresh; so you can use prepared statements (or at least PDO fake prepared statements), so you can let the driver handle escaping parameters; SQL injection is not fun, and even if you know what you're doing, it's easier to let the interface do it for you.

 

[krogen]

Not to start a flame war, but what I think you should learn about ORMs is that they shouldn't be used. Maybe people aren't using ORM tools correctly, but from what I've seen, they are very good at making queries that are not easy for SQL servers to run, and it's very hard to tune the queries as well. If you write all your queries by hand, and see some of your queries show in up the slow query log, it's easy to track them down, and rewrite the queries as needed; but if it's all ORM, it can be difficult to find where the query is built and how to alter the query. I am biased towards high traffic sites because of my experience, but if I'm going to have to hand optimize my SQL once I get to be high traffic, and I intend to be high traffic, I might as well start with hand written SQL.

But yes, definitely use PDO or mysqli instead of mysql if you're starting fresh; so you can use prepared statements (or at least PDO fake prepared statements), so you can let the driver handle escaping parameters; SQL injection is not fun, and even if you know what you're doing, it's easier to let the interface do it for you.

This is why I said to learn SQL first. You should be able to tell what kind of query an ORM will create beforehand.

Well created ORMs have very nice syntax, say: Car.whereid => 1938).onlycolor).limit(1).first(). You can imagine what kind of query this would create right away. A nice syntax makes code cleaner and a million times readable.

Where performance is of utmost importance you can create your own queries but still take advantage of an ORM - extend the ORM classes with your own methods that will perform some custom & complex queries.

Not using an ORM is not taking advantage of available technology. You're only limiting yourself and making your own life harder than it should be.

 

[Fort_Major]

ORM are a crapshoot for beginners; a damned if you do and a damned if you don't.

On one hand they make it really easy for beginners to get started on a project/doing something. On the other hand from my experience, most people who start on ORM never take the time to learn never learn anything about SQL or "good" queries. And that can haunt them or their applications for a while.

 

[ShoeLace]

Well created ORMs have very nice syntax, say: Car.whereid => 1938).onlycolor).limit(1).first(). You can imagine what kind of query this would create right away. A nice syntax makes code cleaner and a million times readable.

Some databases have this type of syntax by default.

For example, here's a quick mongodb example:

car.find({color: 'red'}).limit(10)

That would return the first 10 red cars. No fancy ORM required.

 

[maw]

If you're looking for a career, I'd say it's stupid to limit yourself to learning any one language anyways. In fact, I'd say it's stupid to let the languages you have learned define your skillset altogether. If your goal is to get a career, asking which language to learn is rather trivial, because there are other deeper, more important things to learn than worrying about which specific language you know. A competent professional will be able to transition from one language to another without much headache, and competent employers know this.

Well said, I switch among ASP.NET, Classic ASP and PHP at work all the time. Over the years I've learned the choice of server-side language is way down the list of priorities after things like web security, browser compatibility, usability, accessibility, etc.

Do I know all of a language's features, methods or libraries? Nope. Do I need to? Nope. Sometimes after coding in one language for a while I forget simple things like the exact syntax for declaring an Array in C#, but does it matter? Nope. What matters is that I know WHY I need to use an array. The syntax I can look up in 5 seconds, the skills to know that I need to use an Array takes much longer to learn.

 

[Hellwind]

php

 

[mastaBlasta]

ORM is bad

That statement is so inaccurate and ignorant I don't know where to begin.
First off, any web framework worth their salt uses some form of ORM to better handle associations between models. It reduces complexity, makes the code much easier to read and maintain, easier to test, better security etc.

In most routine scenarios the performance degradation is negligible. A good framework like Rails or Grails will also have significant caching on ActiveRecord and only hit the DB when necessary. You would have to be running a very very high traffic site to need to resort to straight queries. And even then it would only be selective queries.

Straight SQL is extremely error prone.

ORM is database agnostic. Which means the same codebase can work on multiple databases.

It's just a troll statement. It's like saying Object Oriented programming is slow, and you should only use procedural C.

 

[Valkhorn]

Everybody and everybody's mom uses and knows PHP and I feel this makes it a poor career choice. Perhaps a quick-fix job. Depending upon what you're aiming for a PHP position salary might make you happy. It's never once made me even consider calling or submitting a resume. .

A lot of people know it, but they don't know how to do it well. I'm a full time PHP and LAMP developer and I've been doing it for many years.

I dabble in other languages, as all good programmers should.

However, my first language when I was in my teens was C++, and I like how PHP now mimics C++ in a lot of ways. It's object oriented, and you can do a lot with it when you couple it with a good database and database abstraction. When you know how to use PHP well, it can be a very powerful language with a lot of purpose. Sometimes I need to switch to perl or C++ to do something a lot faster server side, or let sql or mysql do some heavy lifting, but overall it's a very well developed language with a very good amount of work in terms of a career path. Plus, you can make bank fixing and improving code written by terrible programmers...

Those that say PHP is a terrible language has only seen it written by terrible programmers. When it's done well, it's a very good language indeed.

 

[Valkhorn]

People learn how to code a few simple server-side functions and call themselves PHP experts. Same with Javascript, where if you can do a jQuery click event, you're pretty much a pro. People think that that's all there is to the language but in fact very few can write robust, secure, fast, scalable PHP applications.

Majority of PHP code out there is terrible precisely because of that. Because people have a low regard for the language and refuse to spend time learning proper style.

THIS. I couldn't have said it better myself.

Look at a sophisticated PHP application sometime written by people who know what they're doing. You'll be surprised at what PHP can do.

Plus, coupled with a good ORM design and database abstraction, it's worth it's weight in gold.

 

[trpwakawaka]

*edit

 

[Fort_Major]

Those that say PHP is a terrible language has only seen it written by terrible programmers. When it's done well, it's a very good language indeed.

Not 100% true. Some people say it because they've used tons of languages and have seen far better languages.

I wouldn't say PHP is a "terrible" language but I would say it is one of the more antiquated of the very mainstream languages. And the fact that it is both open source and in active development makes that a bit more than "a little sad", imho.

There are at least a few mainstream languages that do what PHP does, but much better and in a much more concise manner and with more modern constructs.

 

[Grazehell]

Not 100% true. Some people say it because they've used tons of languages and have seen far better languages.

I wouldn't say PHP is a "terrible" language but I would say it is one of the more antiquated of the very mainstream languages. And the fact that it is both open source and in active development makes that a bit more than "a little sad", imho.

There are at least a few mainstream languages that do what PHP does, but much better and in a much more concise manner and with more modern constructs.

Indeed PHP as a language is flawed. This has nothing to do with how people use or implement it. It has some weird quirks that its substitutes don't.

 

[Valkhorn]

Indeed PHP as a language is flawed. This has nothing to do with how people use or implement it. It has some weird quirks that its substitutes don't.

What language isn't flawed somewhere?

Most of the complaints about it being flawed come from the beginnings of PHP - before it became object oriented and sophisticated. A lot of these are vanishing as PHP approaches version 6.

One of the things I don't like is the inconsistencies with type casting - since C++ is very strict about that. However it is getting better all the time with each version of PHP.

I make a good living with PHP so maybe I'm just biased

 

[Valkhorn]

Not 100% true. Some people say it because they've used tons of languages and have seen far better languages.

I wouldn't say PHP is a "terrible" language but I would say it is one of the more antiquated of the very mainstream languages. And the fact that it is both open source and in active development makes that a bit more than "a little sad", imho.

There are at least a few mainstream languages that do what PHP does, but much better and in a much more concise manner and with more modern constructs.

In my experience the alternatives are never as flexible, or if they are they aren't as fast. The beauty about PHP is that it's so widely available that if you are looking into a particular task you can find a code snippet somewhere and improve on it. I could be wrong, but my experiences with Ruby and Ruby on Rails is that it's much slower and has a very long way to go before it's sophisticated enough in my opinion. It has some neat ideas, but why re invent the wheel for a minor improvement here and there or for some academic peeing contest?

Concise also doesn't mean something is a better language either, or a better method of doing something. There are times when I like for code to take the slightly longer way around because it means it can be more flexible in the future - and can take into account more possibilities.

EDIT: I should note that I've worked with many great programmers who waste too much time being 'academic' and 'intellectual' with their code, instead of just getting the job done properly and done right. It's like calling a plumber to your house and them saying, well for twice as long and more money I can give you special PVC pipes that have a 5% improvement in flow turbulence - but they're proprietary and only I can replace them, and by the way you won't notice any day to day improvements but when I come back and fix things it'll make things easier for me in the future!

I also see the same thing in the 'classical' music world. A lot of new hot shot composer try to write things with so much academic or intellectual fluff and they forget about actually making music. Then they get to catering to particular listeners who love hexachords and tone rows and forget about the 500 years of research into harmonic music that actually produced results. So instead of people trying to emulate Brahms or Bach, they try to throw a bunch of notes on the page based on obscure formulas that nobody will ever get. Oh well, rant over.

 

[tedych]

I'm also in the php world and am a bit biased, maybe.
Of course every language has its flaws here or there. PHP not being an exception and up to the current iterations it has many in terms of naming conventions and types. The loose type handling is one of the most controversial things about it and I think it has its goods and bads. Properly used the loose types can be very useful compared to strict typed languages. Often times I curse it. Sure, it was meant for beginners once, and that'll be its legacy for long time (I don't think it will go away from loose typing anytime soon). Every single thing in the Universe has goods and bads. If it was so bad they'd have fixed it already.
As to naming conventions and functions, they are so bad and I doubt there is anybody not already using some kind of wrappers or framework that goes around this. Unless we have to write super fast code and use the built-in functions more often instead of another level of function/method call.
PHP's strongest side is its huge install base (partly because it's free).

Knowing more languages can always be a plus of course. But as someone said, switching between languages often involves the fact that you forget even simple constructs in a language after writing in another language for some time. And I hold that not every language is good enough for any architectural/design pattern or decision. Using loose types assumes some types of decisions and design patterns which couldn't be equally (or at all) applied to, say C#, and vice-versa. When talking about broad paradigms and patterns like MVC, it's Ok but as someone mentioned the array as an example - an array in PHP could be the best choice for a task (it's actually a hashtable), but in C# it might be completely off sense, or even not possible depending on the app in hand.

As to ORM - I do not use them, I do not think they are needed for any kind of application, I do not need them, I do not think they add any plausible benefits for a semi to high skilled developer, except for slowness . While some kind of abstraction is a must, ORM just adds needless clumsy and flashy dexterity to a realm that doesn't really needs it. Caching is another matter and it can be applied with or without ORM.
It doesn't help maintenance either. My preference is about more moderate level of abstraction, usually self-written - usually by me, actually already done that with few couple of classes, and I'm yet to find a reason it was worse than using a hell-bloated ORM.

"Straight SQL is extremely error prone."
- Nope. It works or it doesn't. ORM cannot build those complex queries for me that I need to pull those fancy reports. Simpler queries are simple with or without assistance. Again - it can be helpful only to beginners.

"ORM is database agnostic. Which means the same codebase can work on multiple databases."
- Not entirely true. Optimizing for one DB cannot work in another. Using a method limit(n,m) is a standard example of something that could work but for something more complex the ORM cannot think instead of me - precise locking of sessions/rows I need, etc.

"It's like saying Object Oriented programming is slow, and you should only use procedural C."
- There are people who stand behind this idea - people with 15+ years of OOP experience. I'm not among them though. OOP is slower, hands down, but it has too many benefits for the modern complex world. I guess it takes ages to come up to this level of thinking about procedural after years of OOP, and I don't completely discard the idea I could think the same as those 15+ years experts sometime. in the future .

And the ORM is not just like the OOP vs. procedural. In its base ORM objectifies a thing that doesn't really needs to be an object, or property, etc. Abstracting the DB is a must however. ORM adds too much clutter, dependency on itself (I hate any needless dependency on 3rd party libraries) and most of all - it's not really needed. At least the OR of the acronym.

 

[robvas]

As to ORM - I do not use them, I do not think they are needed for any kind of application, I do not need them, I do not think they add any plausible benefits for a semi to high skilled developer, except for slowness . While some kind of abstraction is a must, ORM just adds needless clumsy and flashy dexterity to a realm that doesn't really needs it. Caching is another matter and it can be applied with or without ORM.
It doesn't help maintenance either. My preference is about more moderate level of abstraction, usually self-written - usually by me, actually already done that with few couple of classes, and I'm yet to find a reason it was worse than using a hell-bloated ORM.

"Straight SQL is extremely error prone."
- Nope. It works or it doesn't. ORM cannot build those complex queries for me that I need to pull those fancy reports. Simpler queries are simple with or without assistance. Again - it can be helpful only to beginners.

ORM is huge for not having to go back and write queries when your models or associations change. You're seriously telling me you don't use those techniques and write SQL queries all the time?

 

[tedych]

ORM is huge for not having to go back and write queries when your models or associations change. You're seriously telling me you don't use those techniques and write SQL queries all the time?

If you have read my post, I said some kind of abstraction is a must for anything but the most simple or optimized sites.

When your models change, more often than not you have to go back and change something one way or another. Not talking about pure SQL because the abstraction (or active record would take care of simple fields) Example: you add a telephone number field. You have to add some logic to check that out before you supply it to the database. Or fields for addresses - maybe you would check the city/country against a predefined list, or associate a add a google map object to the address. The mere sql would have been taken care of somehow because you don't write sequences of fields=>data in even the simplest abstraction.

A big CMS would have had built-in checkers/validators for commonly used fields like telephones, email etc., but that's irrelevant to our discussion.

 

[Fort_Major]

In my experience the alternatives are never as flexible, or if they are they aren't as fast. The beauty about PHP is that it's so widely available that if you are looking into a particular task you can find a code snippet somewhere and improve on it. I could be wrong, but my experiences with Ruby and Ruby on Rails is that it's much slower and has a very long way to go before it's sophisticated enough in my opinion. It has some neat ideas, but why re invent the wheel for a minor improvement here and there or for some academic peeing contest?

My problem with PHP is not so much the flaws but the speed at which it is modernizing.

Ruby on Rails is probably a great example at doing a lot more with a lot less. That being said, the performance hit you take with RoR can be substantial depending upon what you're doing or how careful you are/aren't.

My personal and professional favorite which imho, has done the best job of balancing the "more for less" without sacrificing "speed". It also has been continuously adapting to support new paradigms as the IT world changes. The latter impo is probably one of the most important things for a language/platform.

 

[Fort_Major]

ORM is huge for not having to go back and write queries when your models or associations change. You're seriously telling me you don't use those techniques and write SQL queries all the time?

Just so people don't get things too twisted.

ORMs are great for small/medium sized projects where you're working with minimal datasets and (quite importantly) your ORM has been optimized for both the database you're using and WHAT you're doing.

Beyond that, however when you're writing complex queries, a majority of ORMs will actually end up shooting you in your own foot by writing queries that will literally be 10 to 10000x more expensive because they're not aware of 10 different things surrounding your query/dataset + your database optimizations.

They are far from an end-all- band aid for anything. The less important whatever it is you're doing, the more useful an ORM is. The more important whatever it is you're doing the less useful an ORM is and the MORE important picking the "right" ORM is.

 

[mikeblas]

Both languages have some pretty serious problems as far as structure and maintainability go. PHP doesn't support threading, which can make things difficult as far as demanding applications go. But I suppose your query wasn't serious, since you haven't returned to the thread in more than a week.

 

[Fort_Major]

Both languages have some pretty serious problems as far as structure and maintainability go. PHP doesn't support threading, which can make things difficult as far as demanding applications go. But I suppose your query wasn't serious, since you haven't returned to the thread in more than a week.

Indeed. Server Side Langauges (like C# 4.5 + ASP.NET MVC 4 ) + Operating Systems who have Fibre schedulers and more, are learning new tricks as far as multi-threading a single request while scaling to hundreds of simultaneous requests.

 

[tedych]

PHP is normally not used for heavy server side lifting. Most of its time is spent in sql queries, and other external stuff, building response, etc. Server side is meant to service multiple requests at a time. This scales well because each request is normally serviced by a different thread or process (CGI). Unless you have only one or two users of your web app, requiring all the server power at a given time .
PHP and threading?! - you'd ask for too much from all those poor php 'experts' out there . If a great need for this arises in the future, no doubt they'll implement it somehow.

 

[mikeblas]

A great need already exists: processors aren't getting much faster; they're just getting more cores. This has been true for the last five years or so, at least.

"Heavy lifting" (whatever that might specifically mean) still happens in the PHP layer: results are sorted, options are applied, lists are processed. Large pages might take a lot of rendering, and spreading that rendering over multiple cores parallelizes the process and reduces latency. If most of the time is spent in the SQL layer, then the website is terribly designed and has no chance of scaling well -- caching is indicated.

Indeed, mutlithreaded programming is hard, but it's also requisite in modern systems because of the pattern we're seeing in processor performance.

Even if you somehow don't agree with these observable trends, the fact still remains that PHP has no support for threading when other, more modern and better-supported languages actually do.

 

[Dogs]

Even if you somehow don't agree with these observable trends, the fact still remains that PHP has no support for threading when other, more modern and better-supported languages actually do.

In my encounters with your 'typical' PHP developer, it seems like most PHP developers haven't done enough work outside of using PHP to know what threading really is or does, so perhaps when it's time to decide what features to implement in newer versions of PHP nobody really has any interest in threading. It might just be a case of 'would PHP developers even use threading if it were available to them?', or something.

 

[tedych]

"processors aren't getting much faster; they're just getting more cores. This has been true for the last five years or so, at least."
- Server processors/systems have been multicore (or multiprocessors) for ages.
'more cores' - yes but not that quickly. And as said, more cores can scale for more load from more users/requests. Average server still got mere 4 or 8 core processors, servicing either one-two heavy sites, or bunch of light sites. Either case, you have several processes/threads that can saturate the cores easily.

" still happens in the PHP layer: results are sorted, options are applied, lists are processed."
- Most of the sorting is (should be) bound to the RDBMS - you don't sort a resultset (or any set) bunch of times per request/second. If you do, you would get any number of cores/server to a state where all other loads become slow, so you should consider some sort of caching. CMSs and web apps use caching of resource intensive operations all the time. It's rarely that you'd have some very valid reason to need all the processing power in a script/request. Usually there are many other requests and sites running simultaneously (and processes - if it's a mail/sql server as well).
Introducing threading in PHP is almost devoid of sense (IMHO) if you think twice.

"Indeed, mutlithreaded programming is hard, but it's also requisite in modern systems because of the pattern we're seeing in processor performance."
- Yes, but not that much needed in most web server scenarios nowadays, as I outlined. On top of that it would introduce Much more bugs because threading requires knowledge that not many of those billions of 'experts' writing code worldwide, have. It's those billions however, who contributed to today's web and it is what it is now, want it or not.

If your app needs threading, go and use another language, it's almost that simple. But PHP driving more than 70% of our web today (not sure about the numbers) is still indicative.

By the way, the new traits addition to 5.4 is really great. Although not quite the same, not many of the widespread languages have multi-inheritance facilities. In the context of PHP traits are very welcome and useful extension.

P.S. Threading in PHP would be welcome by me, anyway. But it should be implemented in a way that is easy for almost everyone. Then it would be welcomed and used. This would be hard because there should be many secondary additions to the language for the threading to be effective. In the simplest form you could instantiate a Thread class and supply it with another object that should run in another thread, with the corresponding new magic methods to support the threading model. Care should be taken considering the fact PHP scripts run in a limited timeframe just to service a request. This would introduce many more problems.