A Look at PHP's Continuing Evolution
acquia.com
acquia.com
There was (another) recent Ruby vs. PHP Bashfest some months ago that was essentially:
"PHP sucks. It can't do X...oh, it can? Well, it can't do Y...oh, it has been able to since 3 major release ago..well, it can't..."
PHP is far different than you probably think it is. I also can't help but feel that a huge number of they people who naysay it are only parroting things they don't even understand - I rarely hear them explain precisely why such and such quirk in the language is bad for programming
Adding new features doesn't help that. Only gradually deprecating old ones (or waiting a few decades) does, and that doesn't seem to be in PHP's blood.
Have you even read a PHP changelog recently?
You're suggesting self-proclaimed radical changes but not giving any information about the actual advantages?
In Perl, variable declaration was originally even worse than it is in PHP: any variable, anywhere, required no declaration and was assumed to be a global. (This was inherited from... some combination of awk and shell, I guess.) Obvious problems aside, a practical implication was that recursion was pretty awkward, since the callee and the caller were sharing the same namespace for the same code.
Perl 5.000 introduced the `my` function, which would declare a variable as lexically scoped. This solved the practical issues, but it left the problem of error-checking: a typo in a variable name would still create an implicit global with no warning. The solution was the opt-in `use strict;` declaration, which disabled the implicit-global behavior and made unrecognized variable names a compile-time error. Code could be fixed and then opt into the stricter semantics on a per-file (or even per-block!) basis, and nowadays most Perl devs will jump on you like a pack of hyenas if your code doesn't start with `use strict;` or some equivalent. Over time other features with too-sharp edges have been culled, still supported by the interpreter (Perl is more or less compatible going back decades) but made illegal in strict mode.
JavaScript's weird "use strict" opt-in is a spiritual port of Perl's approach, stuffed into a string literal to fit into the existing syntax. One of its effects is even the same: assigning to an unrecognized name is now illegal, rather than creating an implicit global.
I'm not aware of anything so fundamental being changed in such a heavy-handed way in PHP. From the outside looking in, I'm not even sure the PHP community has a strong consensus on what PHP-specific features to avoid. I'd be happy to learn that I'm wrong on either count.
i can't think of things that actually come up like that in php these days - things like register globals and magic quotes are long gone..
Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)
This creates an echo-chamber-like environment that's not favorable to the evolution of a rich programming language. Since they never got to learn other languages (at least not enough) its evolution is guided by partial impressions of what other languages offer. It then becomes a collage of partial implementation of concepts similar to what other languages are based on.
Try explaining recursion to someone who only knows 8-bit BASIC (where all variables are global and functions are implemented as subroutines with known input and output variables). It won't work.
I've met more than enough PHP programmers who genuinely tout "it's free" and "you don't have to declare types" as unique advantages, or are unaware that you can even build a website in anything else.
I can't tell if this is a joke or not
Ruby appeared in 1995, the same as PHP
JavaScript appeared in 1995, the same as PHP
Python appeared in 1991, four years earlier
In order to age well, a programming language must not target one specific purpose. PHP is what we would call a template language these days - it was designed, from the start, to spit out HTML. A powerful templating language at that, but it lacks in comparison to most other stacks in that it doesn't have a general purpose language to complement the templating one.
Do you work for north koreans or something?
"working on a remote server" ? you mean editing files on a production box? there is a reason people use revision control and deployment processes you know.
As for "collaboration", IDE's like Komodo have built-in collaboration for pair programming etc. I wonder if you can see the irony when you say you can't use an IDE because a collaborative tool doesn't support it, but then say you don't want to be dependent on a specific tool?
Remote servers are not always production boxes. They may be CI systems or you may need to help a colleague. I'm not becoming dependent on a tool, there are a lot of tools with different features and I switch them all the time. I, for example prefer sublime text for a lot of tasks, and until recently, it didn't have proper PHP auto-completion. Depending on other tools because a language is quirky? No, thanks.
No. It's design should follow a few rules of good language design, which my whatever incidentally does follow too. It may look completely different from my whatever, or to be more precise from any of five or so whatevers I use on a daily basis. One of the rules I have in mind is having small, consistent core of powerful features, which then are used pervasively through the code, instead of having many different one-off special cases. For example AFAIK there is a 'list' keyword in PHP, which makes it possible to assign many variables at once. Why is it a special keyword instead of an instance of built-in DESTRUCTURING-BIND/pattern matching? Or another one: why is there a difference between arrays and objects implementing iterator protocol? Why a few different ways of handling errors instead of one facility?
As you can see I don't tell you how the above problems should be fixed - I'm not trying to make PHP into my whatever. I'm expecting PHP to come with it's own answers to known problems in language design. This may be a bit too much of an expectation, seeing as PHP users won't even accept that there are problems in the language desing...
PHP users can and do accept that there are problems with the language design (because of course they're the ones who have to deal with it), they just choose to work with the language despite these problems.
It is a built-in. Yes, it has a keyword, so what? Why is it a problem to use a keyword? PHP doesn't have deep pattern matching, because PHP is not Haskell :) But it has destructuring matching for arrays, and that's what list() is doing. I still don't see any problem here.
>>> why is there a difference between arrays and objects implementing iterator protocol?
Because they are absolutely and completely different things. Iterators are sequential-access abstraction, arrays are random-access abstraction. Why wouldn't there be a difference?
>>> As you can see I don't tell you how the above problems should be fixed
That's good, because they're not problems :) They are you not understanding what's going on so far :)
>>> seeing as PHP users won't even accept that there are problems in the language desing...
Oh, PHP users know about the problems. Just the real ones, not imaginary "why there's this keyword and not that keyword" and "why are there dollars, I hate dollars" ones. Those are not design problems, those are "everything should look exactly like one language I already learned" problems.
Yes, the problem is that it's not generic, it's only for arrays, and for the ones with numerical indexes (?) only. When introducing a special syntax for destructuring, why not make it possible to destructure other kinds of data, like hash tables? It's one-off special case instead of a generic language feature. In CoffeeScript you can destructure objects as well as arrays, so it's possible for languages other than Haskell. In both in CS and Python destructuring can be used in any position assigment can, including functions formal arguments lists and (in Python) exception handlers. That's a consistent usage of language feature; a 'list' keyword is a hack. I'm not saying it's not convenient to have or that it should have some special syntax instead of a keyword - not at all - just saying that it should be consistently used in the language and well supported by it.
> Because they are absolutely and completely different things. Iterators are sequential-access abstraction, arrays are random-access abstraction. Why wouldn't there be a difference?
But arrays do offer sequential access. The question is this: if both arrays and iterators offer (parts of) the same functionality, why is access to this functionality not uniform? What I'm talking about is this:
"OO brings with it an iterator interface that parts of the language (e.g., for...as) respect, but nothing built-in (like arrays) actually implements the interface. If you want an array iterator, you have to wrap it in an ArrayIterator. There are no built-in ways to chain or slice or otherwise work with iterators as first-class objects."
I'm not sure if it's still the case? If it is, then it's another inconsistency which shouldn't be there.
> Those are not design problems, those are "everything should look exactly like one language I already learned" problems.
I agree that most of the criticism is either unfounded or comes from novice programmers. Novice programmers tend to be loyal to their language of choice to the point of not seeing good points of other languages. I think that most of experienced programmers, however, are already past this stage, with many known languages they can compare and contrast PHP with. It needs to be a fair comparison - I'm not trying to compare PHP with for example strongly staticly typed, functional or concurrent languages. But PHP is a dynamic, scripting language and as such comparing it with Ruby, Python, JavaScript and CoffeeScript, Lua, Perl, Scheme, Clojure, Io, Smalltalk and a few others is feasible. And it's not favorable for PHP, unless we count extra-language features, like community, libraries, ease of deployment and so on. I accept that, with these things in mind, PHP comes like a solid choice and a good language. Based on a in-language features, however, not so much.
Because destructuring hash tables is not a frequent operation that is commonly needed (it would not be hard to do, but I don't remember anybody asking for it in last 10 years). Numeric arrays are used to implement lists, for them destructuring assignment makes sense, as $a[3] is usually not very descriptive if it has special meaning, so extracting it as $option makes sense. Hashes are generic data storage, for them destructuring makes less sense, and $a['option'] is pretty much as descriptive as $option.
>>> it should be consistently used in the language and well supported by it.
It is. You just confusing "well supported" and "meets my expectation". Since PHP wasn't written with you personally in mind, you could find that something you need may be not implemented, because nobody else (within wide margin, nobody actually interviewed every person on the planet) but you ever needed it.
>>> why is access to this functionality not uniform?
It is. See "foreach".
>>> If you want an array iterator, you have to wrap it in an ArrayIterator.
It is not true, unless you need an array iterator object. If you need just an iterator as abstraction, you already have it, see "foreach".
>>> If it is, then it's another inconsistency
I love it how, being pointed that no inconsistency exists between iterators and arrays, since they implement different functionality, change the topic to specific part of functionality and then declare it another inconsistency, though we never seen the first one. Unfortunately, that's how most lists of PHP "inconsistencies" are produced.
>>> And it's not favorable for PHP,
Yet when you had chance to demonstrate it, you chose as your examples - I suppose your strongest ones, since why would you choose the weakest - one case of nitpicking about syntax and one case of comparison of two different abstractions and demanding they would be the same. There are actual inconsistencies and gotchas in PHP (as there are in Perl, Python, Ruby, JS, etc.) but what you're choosing is so trivial and inconsequential...
I believe that I know enough languages to be able to adapt easily to any language. I also think that I can recognize bad design decisions, thanks to the fact that I saw many of them in the making and then - sometimes many years later - these decisions' impact on day to day programming.
To the point: there are arrays in PHP. You can iterate over them with 'foreach'. And you have iterable objects and you can use them with 'foreach' too. Good.
Now, what makes iterator objects iterable is that they implement a certain interface. This interface is public. This means you can rely on it to make your own version of 'foreach'.
Except that you can't, because arrays, most frequent iterables in the language, do not expose iterator interface.
You can say it's irrelevant - but this is inconsistency. And a bad design decision. JavaScript is the same in this regard, except it doesn't even have "official" iterator interface. Both Ruby and Python, however, get this right - everything that is iterable in them implements and exposes the same interface, no matter if it's a built-in or custom object.
You either don't agree that PHP implementation is inconsistent or are unaware of what you could use "custom foreach that works with evereything in the language" for. In both cases you're not a person I want to seriously talk with.
You also arbitrarily assign making and not making sense to things. It's not a good thing that you were conditioned by your language to agree with the decisions its design follows - in the example with destructuring you argue that destructuring hashes isn't commonly needed, while all the arrays in PHP are hashes and you have no way of knowing if the feature would be convenient or often used. You basically believe that generic pattern matching is unnecessary because PHP doesn't have it. You also omitted the part about how - aside from hashes - it would be nice to support destructuring in definitions of functions formals. These two things make the pattern matching support in PHP inconsistent.
You said nothing about error handling strategies in PHP. That means you agree that there being many of them for many different kinds of errors is a bad and inconsistent thing. Functions which fail "silently" in the code but print a warning on a rendered page? "Silencing" them even more with '@'? Seriously? And completely unrelated to exceptions, which are in the language too?
Well, these are not my "strongest arguments" - these are just first things I thought of, without trying very hard and based on a bit dated experience with PHP. I think the most convincing argument is just using another language - or better a few languages - for some time. Of course they all have weak and strong points as well as warts and inconsistencies. But saying that this makes all languages somehow equal and all inconsistencies equally troublesome is just wishful thinking. After some time with Clojure, Python, F#, Erlang, and Go you'll be able to see PHP for what it is.
And it's not a bad language, and you should continue making money working with it of course! Just stop accepting everything it comes with as a "true way". See it's features for what they are: sometimes smart, sometimes stupid decisions made by ordinary guys who sometimes had some insight, but most often just did whatever they thought will be ok and waited to see if it worked. This way you'll be able to push your favorite language forward, which is a theme of this article, isn't it.
You seem to have a very narrow definition of interface (as a set of methods in an object). In fact, the interface that both arrays and Iterators implement is foreach and accompanying functions (key, next, etc.). What you probably imply by interface (Iterator) is a specific implementation of this interface.
>>> "custom foreach that works with evereything in the language"
You definitely could do that, I see no reason why not. You just can't do it with Iterator interface because it's not everything - unlike Ruby, not everything in PHP is an object.
>>> You also arbitrarily assign making and not making sense to things
It's not arbitrary, it's driven by 18 years of actual usage patterns. You may have other notions about what the users should want - but experience teaches us about what they do want.
>>> it would be nice to support destructuring in definitions of functions formals.
Well, that's a bit different topic. I don't believe list()-type destructuring would be very useful, since it's basically just making code more complicated without actually adding any facility not available otherwise. OTOH, destructuring in form of named arguments support in some form - allowing unbounded option lists to be handled easily and naturally - may be useful, and it is one of a real things that is missing - that is a true deficiency of PHP which I know and recognize. I hope it will be fixed one day.
>>> You basically believe that generic pattern matching is unnecessary because PHP doesn't have it.
Nope, I believe it is unnecessary in PHP because nobody has demonstrated a common PHP use case that is hard to solve in PHP without it. If somebody does, I may change my opinion.
>>> You said nothing about error handling strategies in PHP.
Frankly, I didn't notice that. But yes, there are two ways of dealing with errors in PHP - OOP way (exceptions) and non-OOP way (return codes). This is because some PHP users subscript to OOP ways and some do not. You can call it "inconsistency" but frankly I don't see it as such - I do not think language should necessarily allow only one paradigm and force everybody into a single way of doing everything.
>>> Functions which fail "silently" in the code but print a warning on a rendered page?
Printing a warning is a debugging feature, which is very useful when developing the code. Of course, production code, once not in debugging mode, should never do that - and never does. As far as I know, no functions fail "silently" - if they do not succeed, they produce some kind of error code or response. If some do not, it is a bug and should be fixed.
>>> After some time with Clojure, Python, F#, Erlang, and Go you'll be able to see PHP for what it is.
I appreciate your condescension, but in 20+ years in the industry I have had experience with many languages, from Lisp and Prolog to Python, and I can see PHP for exactly what it is - one among many instruments, imperfect but useful in suitable contexts.
>>> Just stop accepting everything it comes with as a "true way".
I can't stop doing something I never started doing. I completely reject the notion of "true way" existing - I think it is you that are approaching the discussion with a notion that you are going to open my eyes on other languages existing (which I knew and successfully used before PHP even came into being) or that PHP is inferior to them all because of some nitpicks that irritate you - which it is not, though it has its own deficiencies, and fixing and improving some of them is exactly what the article is about. It is continually saddens me that any development of PHP produces a predictable wave of hate and condescension, but I assume that is the price of being popular.
It's sort of like when that person with a crush on you who you just don't like but who insists that if you really got to know them everything would be different. It's just not true.
Even if could prove a 1 to 1 correspondence between features of ruby and php, php would still be... ugly. It would still lack grace. The feeling of looking at a page of php code just wouldn't be as pleasing. I believe it is this raw, irrational difference, this visceral reaction to the physicality of the code, and not a misunderstanding of features (even if they are misunderstood) that accounts for the most of the hate you allude to.
There'll always be some degree of learning and adjusting. But a mallet is still an improvement over a rock, because it's designed to fit in a human hand. I doubt anyone scoffed at the mallet and blogged that rocks have 80% market share so why can't we just get over it already.
I think the analogy fails because trucks and sedans are different tools for different purposes (one is better for transporting people, one is better for transporting cargo), while PHP and Ruby pretty much do the same thing, one is just prettier and streamlined.
Says who?
>>> one is just prettier and streamlined.
By which objective measure of "prettier" and "streamlined"?
Says the fact that PHP and Ruby are both object oriented imperative scripting languages that are commonly used for connecting to a DB and spitting out markup. It's impossible to shove a refrigerator into the back of a sedan, but there is no analogous refrigerator that PHP xor Ruby is incapable of hauling.
By which objective measure of "prettier" and "streamlined"?
Well it is subjective, but the nebulous consensus is that Ruby has a cleaner and more readable syntax than PHP.
>>> Well it is subjective, but the nebulous consensus is that Ruby has a cleaner and more readable syntax than PHP.
Consensus of whom? "Nobody I know voted for him", right?
That's a straw man, I didn't use that as a criteria.
PHP and Ruby are both object oriented imperative scripting languages that are commonly used for connecting to a DB and spitting out markup
See that? That's me describing specific qualities of the languages that make them similar. Of course, you could use Ruby or PHP to write a graphics engine (in fact, I have done so with Ruby), but that is not a common use case. Most of the time, Ruby and PHP are used to solve the same set of problems: scripting server-side logic for the web.
Consensus of whom?
The internet? The programming community? That's why I used the "nebulous" qualifier. I'm not saying it's a fact, but it's a pretty popular sentiment which is about as solid as it gets with regard to matters of taste.
Yes, PHP and Ruby are different, but most of the time they are used to do the same thing.
Yes, they are both imperative, non-compiled and can be used to do network connections and output texts. Doesn't really narrow it down. Any further restriction (like narrowing network connections to DBs and texts to HTML or any other specific markup language) just makes it false.
>>> scripting server-side logic for the web
That's closer, but so do tons of other languages.
>>> The internet? The programming community?
See, I just talked to the internet and she says she never told you that.
>>> it's a pretty popular sentiment
Among your friends? I certainly can believe that.
>>> as solid as it gets with regard to matters of taste
Absolutely no problem with taste. The problem comes when somebody tries to declare his taste to be an objective truth.
The process involving the tool which lacks this qualities is more prone to human errors.
Also a bit of emotional attachment to the things you do everyday is good for your mental health. The lack of it is a sign you should change your job or even occupation.
Of course there is. You could, for example, survey developers who had experience with both and ask them. If you wanted to be more scientific, you could randomly select a group of freshman computer students, randomly assign half to a ruby group and half to a php group. Teach the ruby group ruby for year 1 and php for year 2, and vice versa for the php group. Then survey everyone. The point is you are trying to make this into an amorphous philosophical issue, when in fact it's a practical question that does have an answer.
This is not scientific, but it is a personal observation: Most (not all, but most) of the developers I've met who make the arguments you are making and defend php as "just as good as any other language" and dismiss its detractors as hipster bandwagon followers don't actually have that much experience working with a language like python or ruby. It's rare to find people with lots of experience in both php and ruby/python who prefer php. Again, that's not "proof," but it's what I've observed personally.
So objective measure is which language is preferred by more people? I'm not sure how it is an objective measure but I'm pretty sure PHP would win on that.
>>> If you wanted to be more scientific, you could
Nobody even did that. I still encounter a lot of people speaking as if they personally did.
>>> don't actually have that much experience working with a language like python or ruby
That's meaningless argument because it can not be disproven by any possible means - for each counterexample I provide of people that know a lot of languages and still think PHP is ok you'd say "well, and I know hundred PHP developers who don't know any other language". Maybe you do, maybe you don't - how anybody could consider that an objective measure of anything or a measure of anything except the characteristic of people you are surrounding yourself with?
>>> It's rare to find people with lots of experience in both php and ruby/python who prefer php.
What is rare? I know a number of people who could work very well in any common language, but that means nothing - I could also write "I know hundreds of people that know all languages in the world and prefer PHP". Your personal acquaintances don't like PHP, so what? My personal acquaintances don't speak Mandarin. Does it mean nobody speaks Mandarin or Mandarin is a failed language? It just says something about me, not about Mandarin.
Speak for yourself. I love looking at PHP code... Ruby? Well when I look at Ruby code, I think of all the condescending assholes in the Ruby world who think they're language is somehow superior because it LOOKS pretty... Then I base all my opinions on another language SOLELY on how it's syntax looks and nothing more. Because my endusers and customers only care how the syntax of the language I built their site in looks.
This illustrates my point perfectly: Feelings about programming languages are rarely rooted objective analysis. They're rooted in emotional hot points. For some people, those hot points are the aesthetics of syntax. For others, like yourself, they are about social politics.
Rather, I think a lot of the gut reaction against PHP comes from the fact that there is a lot of crappy PHP code out there. So if you ever had to deal with some PHP code, it would not be a pleasant experience.
Likewise, Java has improved a lot over the years, but the popular way of writing Java code with layers upon layers of abstraction, XML config and build files etc. will just turn a lot of people off, regardless of whether it's possible to write elegant and nice code in that language.
As for js in particular, I'd personally argue that it's "merely plain or average" to php's "plug ugly." Although I wouldn't fight too hard for that point, and I'd note that many people who do serious js development actually do have a big problem with how it looks, and write exclusively in coffeescript.
I submit that, indeed, English is the PHP of human languages. It's ugly, its rules are inconsistent and sometimes contradictory, it follows no coherent logical pattern, instead being a hodgepodge of rules and words from various dialects, and it's spoken by too many people who are clearly uneducated, as evinced by their unwillingness to learn to converse in a civilized and syntactically pure tongue.
Seriously, your argument is the same as saying "hip hop is bad music because it lacks the X of classical".
You are fine in saying, "I don't like hip hop because X ", but to say it is "bad" because to you personally it isn't aesthetically pleasing is a foolish argument
That is why people are always calling out PHP because most of the language and most of its developers appear to be in suspended animation.
Developers who use modern tools like Composer, Behat, frameworks other than Codeigniter etc. just aren't that many unfortunately. They're definitely not the majority, like they are over in the Ruby/Python camp.
Nothing at all like the first group of geniuses who decided Rails should store session DATA in a COOKIE BY DEFAULT, or the second, larger group of geniuses that routinely upload the secret token used to encrypt/decrypt said cookie, to public repos on Github/etc.
I think PHP is certainly capable of building larger systems and in recent years things like Composer and frameworks like Laravel are putting a lot of the PHP ecosystem on par with what's available for most other languages.
But I view PHP's sweet spot as small web sites. If you're a small business that needs to add a form or two, some simple DB access, send a couple emails (a few dozen to a few hundred lines of code) PHP is your ideal choice to get something up quickly, get it up on virtually any web host out there easily, and get back to focusing on your business. PHP's lack of elegance doesn't matter all that much when you're talking about a small project.
I think that Ruby/Python/etc are much more elegant when you get to the point that you're building larger web apps, but PHP is a very practical choice for lots of simple projects.
>> I have seen this mentioned many times before, and also worked in PHP development teams. However I think this statement is confusing. There is no way that php development or programming is 80% of the market. I suspect that when you crawl round the internet a lot of spam blogs and advertising content is based off of php based CMS like Wordpress and Drupal - because it is so easy to get a generic template driven website up and running with a good SEO basis. I can believe 80% of the websites that return content could be PHP based.
I would much rather see a conversation about how other languages can bridge the gaps of "hello world in a browser isn't obvious" and "deployment is hard". Those are important and useful things to do, regardless of PHP's market share.
PHP requires opening index.php and typing "hello world". Obviously that's not going to work anywhere else, but something like Flask (or Sinatra) is much closer.
Deployment, maybe. The biggest stumbling block is that no matter how magical a deployment solution anyone invents, it's worthless unless there are free/cheap hosts that come with it installed and have cPanel integration.
and the methodology:
http://w3techs.com/technologies
"We investigate technologies of websites, not of individual web pages. If we find a technology on any of the pages, it is considered to be used by the website. We include only the top 10 million websites (top 1 million before June 2013) in the statistics in order to limit the impact of domain spammers. We use website popularity rankings provided by Alexa (an Amazon.com company) using a 3 months average ranking. Alexa rankings are sometimes considered inaccurate for measuring website traffic, but we find that they serve our purpose of providing a representative sample of established sites very well."
I would argue that the numbers should be weighted by traffic - weighting all of the top ten million websites equally doesn't give an accurate picture.
One major feature not listed on the submitted article is namespaces, which is fairly major and it's just starting to reach critical mass in terms of reach. Despite being probably the most major feature in the past five years, most users should be able to enjoy using namespaces to their heart's content (along with all the libraries that utilize it, for example Amazon's latest PHP SDK (which is thoroughly impressive)).
For reference, Python3 came out in 2008 and it's also just starting to reach critical mass in terms of library support (cough third-party Django libraries).
There is also a third-party committee[1][2] with the goal of establishing things like coding guidelines, logging interfaces, HTTP request/response interfaces, and so forth.
The difference is a fairly large undertaking both in code size and technical challenge.
They never set out to "define the best way to do X". They set out to "find the most common way the most common frameworks do X".
The results are equally questionable. Why would a "Framework Interop Group" need to care about shit like brace placement, indenting, or even file naming.
Their file naming is a big wtf for me, as their "standard" is set out the way it is, to support faux namespaces in pre php 5.3. PHP 5.2 reached 'end-of-life' status 2 1/2 years ago.
What gets me even more is the fucking hoops people constantly jump through to make ever more complex autoloaders for PHP.
there is native support in php for autoloading class files, including namespaces. it takes one line of code to set it up. one function call.
But that's not all: when these geniuses decided they wanted to implement a "reference" class loader, what did they call it? SplClassLoader. Because if enough idiots already follow your shitty "standards" they will think "ooh spl is in PHP this must be endorsed by them too!"??
Their logger interface is fucking laughable - who implements a logger, that has names exactly the same as syslog, and descriptions the same or similar to syslog, but ignores that syslog levels are INTEGERS and thus you can say quite easily "email be about errors below level x"
Just sayin'.
I wouldn't say so. Most species (read: groups, not individuals) adapt when nature throws an exception they can't handle. Mutations capable of handling these exceptions become predominant in a group, while obsolete gene pools die off.
PHP shows too little of this for its progression over time to be called "evolution."
Wait...
In other words, PHP is definitely becoming a better, more reasonable language.
Of course it's still possible to write awful code using some old PHP features. But it's now far easier to write good, maintainable and expressive code, as one would in Python, or Ruby, or Go, or [you name it].
With this regard, PHP's evolution is not unlike C++'s.
Comparing PHP's evolution to C++ isn't exactly flattering either.
Since PHP has $$var (and other things like this) we can not know in advance which variables the function uses in local scope, so if we did automatic scope importing, we'd have to keep the whole scope of the parent function for the lifetime of the closure in case some of the variables would be needed. This, if parent scope contained some large objects, would result in a memory and performance hit each time closures are used.
Thus, it was decided that we'd make scope importing explicit (the use clause), so if you want to import variable, you have to say it. Experience shows that vast majority of closures need no more than one or two vars from parent scope, so the tradeoff is fine. Of course, if closures would import dozens of variables regularly, we'd have to seek different solution, but this is not the situation.
Additional benefit - though not the reason - is readability improvement, as now you know where each variable is coming from, otherwise reading in-closure code you wouldn't know if the variable that is not mentioned anywhere is a mistake or it is actually expected to be imported from outside.
BTW, C++11 is using the same idea: https://en.wikipedia.org/wiki/Anonymous_function#C.2B.2B though they have catch-all syntaxes which in PHP wouldn't work since PHP is a dynamic language.
I still think it looks weird even if PHP's semantics make it necesary but that's totally subjective :-)
Whatever helps you sleep at night.
Lots of start-ups started with PHP (foursquare, groupon, facebook, etc, etc) because of the minimal cost and the convenience offered by popularity. If it works out and they get funding they can spend all that sweet cash on whatever they prefer.
Mobile apps and heavy REST services maybe not, but websites are still popular, and PHP is playing catch up for those services too.
I spent the start of 2008 migrating an agency off CodeIgniter - it definitely improved their projects afterwards (developer training helped too, but not as much as a well-designed framework did for code reuse).
What gets me is CodeIgniter is how I was writing PHP code back in 2003-2004, 4 years after picking up the language as a hobby. And people still think writing it like that is a good idea.
What else would they want people to think?
I guess it could all depend on your definition of 'anytime soon', but 5 years, 10 years from now, will PHP still drink 80% of the proverbial milkshake?
Using mod_php? Better fix your file permissions. Use any non-trivial language feature? - better make sure you have the right minor version installed. Use functions from the supposed standard library (e.g., anything from gd_*, xml, process control, cryptography modules)? - better pray PHP was compiled with those enabled. Use routing in your PHP app (and you're crazy if you don't)? - better pray apache is configured to accept your .htaccess, or port the mod_rewrite rules for the non-apache server you're on. And then all of this while futzing with the 3 different php.ini files scattered around the filesystem.
Between virtualenv and pip, deploying python has been loads easier, as is getting team members up and running with a dev server.
Every one of your examples tells me that you chose not to invest in those 20 minutes.
Here's a hint: there is a reason "developer" and "administrator" are usually different roles.
I'm not saying I chose not to invest in those 20 minutes, I'm saying there's nothing about PHP that makes it inherently easier than other things to deploy real projects. You still have to deal with version incompatibilities, you still have to deal with configuration, you still have to deal with differing resources. That applies to all stacks.
HN can be an echo chamber for Ruby, Python and Golang. But outside of the Bay Area, a lot of people are very excited about Symfony2.
-FOSUser -FOSRest -Sonata Admin
In a few minutes, I have a multi-user website, complete with REST server and a user administration interface. As someone without a lot of hands-on experience with Laravel, is there a similar combo of Laravel bundles that can get me up and running with a multi-user website?
Laravel 4 is becoming the CodeIgniter of the PHP 5.4 frameworks - simple enough for people to jump on as they can get something done. And the CodeIgniter comparison is not a compliment.
* Forms? It has support for forms in more way than one. Read the docs! :-)
Thanks, I had a look about a year ago at the facades document and it seemed a justification for using static methods, rather than a reason.
I'm pushing hard on this as I really want to understand it. I am surrounded by PHP programmers chanting "Every time you use a Singletons a kitten dies" and "No static methods". Yet when I used (and contributed to PEAR) they were positively encouraged. Is the change another fad, or fact-based?
> * Forms? It has support for forms in more way than one. Read the docs! :-)
I have :) I see helpers to generate form fields and a validation library. I see no way to create form entities, to extend forms (to create variations on a base form), or to abstract the field definitions from the view (while the visible value of select box options could be in the remit of the designer, modifying the value shouldn't be accessible to anyone other than the programmer, and neither IMO should choosing the field type (drop down or multiple radio buttons? Multiple select or checkboxes?)
Also no support for 0..N repeating fields baked in (with conditional validation), or 1..N fields - stuff I use in almost every form. Every form library I've discovered falls short in these requirements though!
Let's say you want to hammer in a nail. You reach into a tool box and pull out something that you think is a hammer. Instead it has claws on both sides, and is in fact a nail puller. You don't know much about tools so you use it to beat in nails, all the while grumbling to your friends that it's a bad hammer.
For instance, I don't see how you expect to "solve" most of the "issues" in that. The fact that the author does not like the way == works in a weakly typed language is not a bug. Sure, it present bugs in code when programmers don't know how implicit type casting works, but it's really nice if you do.
I don't see how to solve most of the issues, either. That sucks, and I genuinely sympathize with Zend on this, but it doesn't make them not-issues. As I think I said, they'd be acceptable if they were reasonable tradeoffs, but many of them are not.
Your == counterargument seems apologetic and trivially applied to anything: whenever a program is wrong because the language violated expectations, it's the programmer's fault for not having memorized some matrix of arcane rules. Languages aren't perfect and human beings have wildly differing expectations, but ultimately we only have programming languages to make it easier to express ourselves—no one's stopping you from writing the next big web 2.0 thing in x86 machine code. So yes, when it's difficult to reliably ask a language "are these things the same" without learning paragraphs of gotchas, that's bad.
Glad you enjoyed the article!
its a language, you learn it. it doesn't adapt to you.
I am slowly learning Thai. I am fucking terrible at it. I mean absolutely woeful. It's hardly the fault of Thailand or its people that their language has different sentence structure and different words than what I'm accustomed to, is it?
Type juggling exists, there is an operator that does a strict comparison.
Build a bridge and get over it, and yourself.
There are no strict comparison operators for less-than/greater-than. === acts fundamentally differently for objects than for everything else. Alas.
Talking about == is not trivial or apologetic. That's the way I expect comparison to work in a loosely typed language. I expect 0, 0.0, '0', '0.0', -0, 00, 0x00, null and false to be logically equivalent most of the time. If it also means that if I don't validate input from an http request 0=='0 foodle fish' also evaluates as true, then that's a cost I'm willing to bear.
I don't see how this is anything but bugprone, and all to save you from actually saying what you meant and slapping a couple int()s on your input.
Compare JavaScript, a language with much the same == problems, where the community generally advises against ever using == at all. CoffeeScript (different syntax that compiles directly to JavaScript) even translates == into ===, leaving the original buggy operator unavailable.
I don't think 0 == "zero" is a meaningful comparison, so I don't think there is any single sensible answer. I know "zero" will be cast into 0 and therefore it will be true. That's not a matter of expected language logic, it's just personal preference on do you want your language to fail hard when given garbage input, or continue.
Most input to a PHP program is going to be strings. It is going to have come from an untyped GET or POST request string decoded into string parameters. If you expect it to be integers it needs to be cast somewhere. For most applications you should be doing that explicitly, taking control of the process and deciding how to respond to user error or other invalid input.
Our main difference of opinion seems to be that I think it is good that the language tries to help when the programmer is lazy, and you think it should immediately reprimand them with a rolled up newspaper so they will be forced to do it properly before seeing any output.
My problem is that the language is guessing wildly, in ways too obscure to be mentioned in the documentation or known by you (a user of the language), even when both operands are strings. That means it appears to work much of the time even if you don't think you're being lazy, but might actually have a bunch of false positives you didn't expect. And that's kind of a bad thing in a programming language. Same sort of reason manually escaping everything is hard to get right: if you forget, your code still works fine under "normal" circumstances.
Now, if == did a strict comparison and there were a separate imlazyjustslopittogether operator, there wouldn't be a problem. Defaults matter.
We now use Composer for packages, an automatic classloader, an application framework and a database abstraction. But even with all this stuff, PHP is still an incredible pain.
PHP might be good at the situation where: on every request, you start a new script, that builds a webpage and sends it to the client. But once you try to make it do something else... Frustration awaits.
What difficulties are you encountering trying to do basic pub/sub? Application developers have solved those exact same issues for decades now. Nodejs didn't invent "event-based programming".
If you know of a PHP runtime-host, library, or even just a development approach that makes supporting it as easy as nodejs, though, I'm all ears.
For the same reason, Python is virtually nonexistent—because nobody uses mod_python.
This page was also interesting... Keep in mind, it's only the top 10,000,000 in Alexa: http://w3techs.com/forum/topic/22677
"In total, we have a few thousand technology indicators, many of them can be used - directly or indirectly - to determine the server-side language.
The number of sites where we don't identify any language is relatively small. The reason why we don't include it in the statistics is, that we want to show shifts in the relative popularity of technologies, not distorted by changes in our abilities to detect them."
Many developers (especially ones building upon CMSes primarily) don't need to move beyond knowing Wordpress, ExpressionEngine or CodeIgniter.
So many "easy to use" products are built on it (Wordpress alone powers ~18% of "the internet") that it makes sense that we see so many mis- or un-informed developers crowding Google and StackOverflow.
You can make good code in PHP. You can also learn other languages. You can, more importantly, learn when it's a good idea to use other languages. However, if people don't need to learn more, many won't. That's human nature.
Saying "PHP sucks" is missing the point that other people have other needs, other experience and other education levels from you.
PHP, as a language with low barrier to entry, can fulfill many's needs without requiring a CS education, and without writing their own framework/cms.
Source: 18% of internet: http://thenextweb.com/insider/2013/07/27/wordpress-now-power...
It's not a bug, it's a feature. PHP is by design the language for young, inexperienced developers. It's like saying the only problem a school has is that it's full of kids.
PHP is an actively developed language. It has its pitfalls and problems, but is also provides more modern ways to use the language that avoid those problems.
Javascript is popular because people have no choice but to use that. Let's be truthfull here.
Only a few people actually like this language.If it wasnt for the web nobody would use javascript ,which is totally inconsistent with the strongly typed DOM.
Kudos to microsoft as they created DHTML.
[1, 2, 3] ['key1': 'val1', 'key2': 'val2']
We've been on 5.4+ at work for some time now and if I'd know that a year ago it would've saved me a lot of array()s and visual noise.
What went live in 5.4 was support for brackets in lieu of array()
// Typical array syntax
$arr = array('key' => 'asdf');
// Supported in 5.4+
$arr = ['key' => 'asdf'];The actual problem is that PHP automatically initializes variables even on read—the same reason all globals have to be manually "imported", even if they're only read from. Similar to the problem Python 3's `nonlocal` solves, except imagine a world where Python didn't have NameErrors and instead initialized every unrecognized name to None.
I suppose they could have made it work differently just for nested functions, but that's a major inconsistency, it's not clear how it would interact with globals, etc.
register globals imported request parameters from the query string and post body into the global variable scope.
having undeclared variables "act like empty strings" is related to non-strict variable comparison (== vs ===) and either silencing errors, or not displaying/caring about them.
of course it could be a security issue without undefined variables coercing to an empty string in string context - it could allow request parameters to override defined variables.