I don't think unguided is an appropriate descriptor for an evolutionary process (by definition or in the scope of PHP's history). However, your point about success is right on, and seems to fit the 'evolution' title and the language.
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."
I don't think that's accurate. There's not really any notion of "success", and the most important part of the process is that changes are made effectively at random and either propel the species forward by some minor increment or never make it past being rare curiosities.
In natural languages, words have multiple meanings. You may want to actually choose one that fits the case, not one that represents it in most perverted and unfavorable light. Just sayin'.
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.
Why is Python 3 relevant? Porting a large Python 2 library to Python 3 (or, more likely, to both 2 and 3) is a significant undertaking. Porting a PHP library to use namespaces would largely be a matter of adding global aliases for backwards-compatibility, surely?
Porting a library from non-namespaced to properly-namespaced code is fairly significant, and there should be little-to-no backwards incompat. issues between pre-php-5.3 and post-php-5.3.
The difference is a fairly large undertaking both in code size and technical challenge.
I have to say I think the php fig is a joke, and I question the merits of anyone using it. Their own goals are a joke, much less the results.
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"
The most-used logger implementation (Monolog) supports "email me errors below x", even though the log levels aren't integers (if you're right, haven't checked the internal code to verify)
Why not? , programmers might hate it but they don't always drive start-up direction. Getting something to market and being useful is just more important than semantics when you're facing a budget.
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 don't disagree. I was responding to the sarcastic comment about PHP, not really trying to address using it for a start up. Our start up used it as well. It's not the sexiest or most fun environment, but it works and it's the devil I know.
This is my situation too. I mean, I know PHP and I know CodeIgniter. I have tons of already ready to deploy code based in those idioms, so why port everything to laravel? or Ruby? Maybe down the line or something... but not when speed matters.
How about because CodeIgniter is one of the worst frameworks around, which provides little support for separation of concerns, avoiding spaghetti code and general maintainable programming practices.
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.
Not being cynical about its incontrovertible success. I'm being cynical about the context of the statement -- Acquia is a company heavily invested in PHP / Drupal.
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?
Really? They have been around since 5.0, which is nearly a decade old. See some of the other interfaces SPL provides here: http://php.net/manual/en/book.spl.php
Generators mostly are just a convenient syntax for iterators (i.e. if you wanted, you could have generators years ago, just required to do some awkward boilerplate code).
I'm pretty sure w3techs is just measuring who has what in their `Server` headers, so even a static site that happens to have mod_php available would still ping as PHP.
For the same reason, Python is virtually nonexistent—because nobody uses mod_python.
"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."
PHP's continuing evolution is also represented by the frameworks available for the language. For instance, Symfony2, paired with Composer, is (IMHO) analogous to Rails for Ruby and Django for Python.
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.
One of the things I love about Symfony2 (other than the framework) are the following bundles:
-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 has built-in auth support and a bunch of good Composer packages that can add more features. It's also got RESTful and resourceful controllers built in and a very awesome routing system. You can use any admin/cms package, but this one I made specifically for Laravel and the Eloquent ORM:
Laravel 4 is amazing, too. Symfony2 feels like a beomoth to me (a few versions later and it will probably be on-par with Zend in terms of over-architecturing as it is going right now) whereas Laravel is lean and elastic yet offering the complete package in an easy consumable format.
I'm seeing a lot of love for Laravel 4 at the moment and I'm not 'getting' it. Sure, the framework's easier to pick up than Symfony2 and not as over-engineered, but it doesn't feel as complete (forms, anyone?) or as well designed (what's up with all these static methods?)
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.
Laravel doesn't come close to CI in terms of trash. It is very well architectured to the point where everything is modular, testable, properly documented and done with a reason. Static methods are actually facades as pointed out and are key in having proper testable applications.
* Forms? It has support for forms in more way than one. Read the docs! :-)
> Static methods are actually facades as pointed out and are key in having proper testable applications.
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!
I don't find the closure syntax simple really, since it's essentially a hack to copy the variable into the current scope, since PHP doesn't support lexical scope.
PHP supports lexical scope; it's just local to the current function.
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.
Is there much PHP code that relies on this "feature" or could they have changed it to actually search in the enclosing scope if something was read, and avoided the silly "use" keyword? I mean it's not like PHP has an actual spec, so they can change it whenever they feel like it as long as it doesn't break much.
Variable declaration is pretty core to the language. Remember register_globals? That was only a problem because so much code relied on having undeclared variables act like empty strings.
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 didn't "make undeclared variables act like empty strings".
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.
register_globals could not have existed without the legality of undeclared variables, and it could not have been a security issue without code that relied on using undefinedness as a default value.
undeclared variabels aren't legal, they cause errors. if your php is configured to ignore those errors thats on you.
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.
I have to create some push based (websockets or similar) web service that's event driven (events on the stock market). The prototype has been written in PHP, but doesn't do very much. I'm STRONGLY considering moving to nodejs.
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.
Your worldview ( Your last statement, that you think PHP is only suitable for a single request in a fcgi environment.) of PHP's capabilities are the pain point here.
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".
Event driven programming seems tacked on to php. I don't know if I want to run php as a daemon and then do some hackery to get IPC. It's not made for that...
I've written a lot of PHP, and while I can think of a number of ways you might use PHP to provide the backend for websocket-like communication (writing a long-running server, using multipart responses, adaptive polling), it seems pretty fair to me to say this isn't the place where PHP is strongest out of the box. Particularly compared to nodejs.
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.
"That 80% marketshare is not going anywhere anytime soon."
>> 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.
This is maybe the third comment about whether the 80% is lies, damned lies, or statistics.
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.
With what? Rails? Doesn't that require generating a whole "project" (whatever that is) with a bunch of directories and files and then figuring out where everything is and...
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.
"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.
There is so much to dislike about PHP that the only thing I can say nice about PHP is that it's the easiest way to just deploy to any server ever. Beyond that, I don't think I would look to PHP to do anything ever if I had a choice of project language.
As someone that has had to mess with deploying large PHP project in a previous life, I'd have to disagree.
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.
Out of the box php generally works, which is often touted as a benefit. Personally i think if you can afford a server you can afford 20 minutes time for someone who knows what they're doing.
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.
Out of the box php generally works so long as you have trivial php code (that doesn't take advantage of new language features, doesn't need routing, doesn't need to write to the filesystem, and doesn't common library modules). Needless to say, that generally rules out any serious project out there.
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.
I doubt that many of the main gripes about PHP will ever be solved without a "breaking changes" version like python had. The PHP community isn't likely to get behind something like that.
I've always loved that fractal of bad design rant. Many of his gripes follow really neatly from his initial analogy of the hammer with claws on both sides.
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.
Hello, author here. You're not the first to scoff at my hammer description, but perhaps you can explain to me what kind of nail puller looks exactly like a hammer but with two claws, or why it would be useful to have the exact same tool on both sides of the handle. (This is still a PHP analogy.)
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.
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.
The people of Thailand didn't invent Thai, and it's unlikely that a handful of them could invent a new language and have it catch on within a few years. The analogy doesn't quite hold. Switching sentence structure is more akin to switching paradigms, anyway.
There are no strict comparison operators for less-than/greater-than. === acts fundamentally differently for objects than for everything else. Alas.
I think you are stretching the hammer analogy well beyond its useful limit. I've no idea what php function you think has a redundant left and right version, but to humor you, sure there are lots of nail pullers that have two similar sides or ends to attack different sizes.
eg http://s.shld.net/is/image/Sears/00938076000
There are also lots of physical tools that completely reasonably do have exactly duplicated sides or ends because they wear out, but I don't see how you want that to apply to software.
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.
Would you expect "1.30" == "13e-1", since both are strings? How about "0xb" == "0xB"? 0 == "zero"?
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 would not expect "1.30" == "13e-1" or "0xb" == "0xB" to compare as true, but it's of kind of cool that they magically do.
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.
It's good when languages try to help. Reprimanding someone for not doing enough work is useless.
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.
On topic: PHP gets lambdas and closures; generators; traits.
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.
That has to be one of the strangest syntax's I've seen for closures ever. I get why it has to be that way sort of. (backwards compatibility) but it only serves to illustrate how PHP has hamstrung itself in the past.
Comparing PHP's evolution to C++ isn't exactly flattering either.
What's so strange in it? It looks pretty much exactly like JS, for example, with one small addition of "use" clause. It has very little to do with "backwards compatibility" - since there's nothing to be backwards compatible to, closures didn't exist before.
The use clause is the weird part. I would imagine the reason it has to be there is because it would be bad if functions that weren't written with closures in mind previously suddenly turned into closures. Otherwise why even bother?
The reason has nothing to do with that. The reason is that closures don't need most of the variables from parent scope, but if they were imported, since PHP is refcounting they'd keep a lock on those variables even after exit from the original scope - as long as the closure exists - even though nobody actually needs them.
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.
There is something almost endearingly quaint about the author's earnest excitement over a verbose closure implementation and a procedural incarnation of the map method, like hearing a hunter-gatherer describe in awe the magic pictures in a box which is in reality a junked television set from 30 years ago.
Mmmmmm, sweet condescension. Nothing floats my boat higher than expressing superiority to PHP developers. They actually consider themselves to be real programmers, aren't they just the cutest?
GP's phrasing aside, it does make the article read as though the author has never used any other closure implementation (and, by extension, any other programming language).
Well, perhaps he hasn't used any other closure implementation... why would that merit mockery? I doubt the same tone would be taken if he were a Ruby novice adulating over block syntax. It's just hip to condescend to PHP developers.
I'm only observing that the article comes across weirdly as a result, especially when the author makes judgments like "simple". Not defending the condescension. (Though the same tone might well be taken if he were a Ruby novice writing articles titled "A Look at Ruby's Continuing Evolution".)
This article is important because there are still so many people who talk about how bad PHP is, based on their knowledge of some version from years ago.
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
I mostly agree with you. The awkward syntax and a nightmare API is here to stay for backward compatibility though. The most important point is, there are a lot of languages which are better than or at least on par with PHP on every aspect you can think of. PHP is definitely not a disaster, but everybody just need to move on.
Nobody needs to move on. PHP is here to stay and isn't gonna disappear anytime soon, it controls a large portion of the internet, if you don't like it, don't use it. Nobody is forcing you to use it.
Nobody needs to move on from COBOL. It's here to stay and isn't going to disappear anytime soon. It runs a large portion of all financial operations. If you don't like it, don't use it. Nobody is forcing you to.
Good. I'm glad you're catching on. Next step is to learn that all languages have their strengths and weaknesses and your personal preference means nothing to anyone but you.
Now, this is not really an argument but more of an emotional response, isn't it? What I see is that PHP is already losing popularity by every passing day. How many newbie developers are starting with PHP these days? Why would they? It's not as bad as people make it to be but there are just too many better alternatives, which are also easy to learn. I honestly don't get this kind of defense.
> What I see is that PHP is already losing popularity by every passing day.
And where are you observing this at? I hang out in PHP communities and I am seeing more and more new faces daily. Lots of new people starting with PHP because of it's easy use and the fact that the most popular open source projects to get your site off the ground are PHP based.
...with just too-many-to-count alternatives. Those projects are also usually not for seasoned programmers. Who uses Drupal for anything serious these days, apart from maintaining it? What is the user-base for Wordpress? Take a look here: https://github.com/trending , How many are written in PHP? It just doesn't make sense to start something new with PHP unless your existing code-base is written in it.
PHP's worst problem is an exacerbated form of what strangled Perl for many years (and still does, though they're actively fighting it): lots and lots of existing code that's really, really bad.
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.
PHP has deprecated obviously insecure behaviors that are largely Web-related, yes. I'm coming from a Perl perspective, where deprecating bad language features means things like "radically overhauling how variables work" or "putting major community effort into eliminating an entire kind of variable". I'm not aware of many similarly-radical changes in PHP, except perhaps whatever happened with PHP 4's short-lived classes.
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.
thanks for the info - it makes sense now. its a similar issue to non-declared vars in js as you mentioned, but even then that was not a language fault per-se, it's just a lack of knowledge about the language.
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..
I disagree that it wasn't a language fault; it provided very little benefit and directly caused hard-to-diagnose bugs. Being told where the mines are doesn't make walking across a minefield any more palatable. If it were a good idea it wouldn't still be around.
Undeclared variables in PHP produce an E_NOTICE, right? Better than Perl 4, at least. :)
PHP's worst feature is programmers who only learn PHP. Even worse when they become the most vocal members of the community.
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.
It is rather telling that PHP's design is based on whatever was popular at the time. The original design was based on Perl, further additions and the stdlib were designed like C++, the class system is a lot like Java, and recent features have been clearly inspired by Python.
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.
Now days the only valuable thing a naysayer can say anymore regarding PHP is the inconsistent naming and needle/haystack placement, which really makes no difference other than to be a slight annoying having to go to php.net/function_name and just make sure it's right.
Why would you keep looking at php.net when there are better, modern, easier to write alternatives? Cheap hosting? Come on, we're living in the days of 5$ VPSs.
Of course, I sometimes forget if a function is function_name or functionname so I may as well just give up and just spend all my time learning a new language, all because I can get a VPS for $5... Sounds logical. Let me tell my boss he's gonna pay me to learn a new language because I couldn't remember a function name and tell all my clients they're gonna pay me to rebuild all their stuff in another language for the exact same reason!
If you already have a PHP shop with paying clients, well, there's no reason for you to. However, you have to be living with the fact that someone of equal talent as you would have a significant advantage to you, just by using modern tools.
They had no problems with breaking the compatibility when being developed and they were better designed to start with. PHP started as a quick and dirty alternative, therefore gained respectable traction, became worse by trying to answer all needs, now it tries to be like others. Why? I don't hate PHP. I love it for what it helped create (most of the popular websites is a start). It's just isn't the best at anything anymore.
I never mentioned compatibility. someone said it's old, and i refuted that point, as its the same age or younger as three of the languages most often compared to it
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.
Why do either when a decent IDE will let you use whatever fucking language you want and give statement completion and hinting. Fuck me it will even insert the braces and parenthesis that are apparently the bane of ruby and python developers lives.
No, for example when I'm on battery, or working on a remote server. Collaborative coding tools are also missing most of the IDE features. Why would I want to make myself dependent on an IDE?
i am completely not getting the link between an IDE and your battery?
"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?
Using IDEs lead to higher CPU usage, that makes the battery die faster.
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.
Php still sucks, but the community is trying to build tools around it to make it better. But it doesnt make the language itself good. To make it good the first things to do would be to remove 90% of its silly "features".
You mean, for you to like PHP it must cease to be PHP, die and be reborn as your favorite whatever. Sorry, not gonna happen. I guess for you it will suck forever.
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...
seeing as PHP users won't even accept that there are problems in the language design
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.
>>> Why is it a special keyword instead of an instance of built-in DESTRUCTURING-BIND/pattern matching?
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.
> 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.
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.
>>> why not make it possible to destructure other kinds of data, like hash tables
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...
> Since PHP wasn't written with you personally in mind
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.
>>> Except that you can't, because arrays, most frequent iterables in the language, do not expose iterator interface.
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.
To give a serious answer to this: While you are right that php bashing isn't always rooted in informed objectivity, the point you're making is missing something deeper.
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.
I personally think if you have raw, irrational, visceral reaction to programming languages, there's some priorities problem here. Those are tools. You're supposed to use them, not fall in deep emotional love (or hate) with them, that's what you do with people, not tools. I know this opinion may be unpopular and I know people do fall in love with tools (and use people) but I think they're doing it all wrong.
Tools should be designed to fit with humans; the goal is to minimize how much humans have to contort themselves to fit their tools.
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.
That's fine. People have different needs and preferences. Some drive Honda Accord, some drive BMW convertible and some drive GMC truck. It's just looks a little silly when Accord driver comes out and starts pronouncing that trucks are absolutely useless and he has deep visceral hate with anything that ugly stupid space at the back that nobody ever needs and millions of people that buy trucks are actually idiots just incapable of driving a clearly superior Accord.
I'm not sure how to reconcile this analogy with the existence of government programs (carpool lanes, tax incentives for hybrids) that encourage the use of more efficient cars with more people in them, on the grounds that it's better overall for the ecosystem.
I sincerely hope you don't imply you'd like government coercion to be used on people "for their own good" when they choose what tool to use for their purposes. Or for the government bureaucrats to select winners in software world and facilitate wealth transfer from actually popular tools to those that are only viable as beneficiaries of government coercion.
I think his point is that the truck analogy doesn't favor PHP when he considers that society has made an effort to reduce the use of trucks due to their general inefficiency compared to sedans.
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 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.
Any Turing-complete language can do any computational task that is computable by Turing-complete languages, so by that criteria every language is the same. Obviously, in practice they are not.
>>> 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?
Any Turing-complete language can do any computational task that is computable by Turing-complete languages, so by that criteria every language is the same. Obviously, in practice they are not.
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.
>>> That's me describing specific qualities of the languages that make them similar.
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.
It's not about love. Applied to programming tools beauty/ugliness describes a set of special qualities: expressiveness, readability and mathematical symmetry of it's structure.
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.
The problem is that if you look into the things these qualities applied to, you'd find that correlation between virtually any objectively measurable quality and love feelings expressed is minimal to non-existent. There's no objective measure by which you can conclude Ruby (as an example) is "more readable" than PHP. Of course, you can say "it's easier for me to read Ruby", but that's different thing - it's pretty easy for me to read Russian, but that doesn't mean I get to claim Russian language is superior to Mandarin, which I can't read at all, or to English, which I can read as easy, but probably appreciate the subtle meanings of it less. Yet more it doesn't make sense to me to express visceral hate for Mandarin each time it is mentioned anywhere or express my loathing and disgust to anybody that keeps using it, despite its obvious unsuitability to any practical purpose.
> There's no objective measure by which you can conclude Ruby (as an example) is "more readable" than PHP.
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.
>>> Of course there is. You could, for example, survey developers
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.
> The feeling of looking at a page of php code just wouldn't be as pleasing.
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.
> 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
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.
While I agree with you that some languages can be prettier than others, I don't really get why this would be a problem, if you're talking about syntax. You could say the same about Javascript, yet projects like Node.js are gaining popularity and are quite popular with the HN crowd.
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.
Well clearly language popularity is a more complex beast than mere aesthetics. I'm only saying they do play a part, and probably a bigger part than most admit.
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.
There is a lot of crappy PHP code out there, it is absolutely true. There is also a lot of crappy English poetry out there and absolutely disgusting and mind-bogglingly stupid English prose out there. And there are people that have to deal with that daily. Should we conclude English is a failure as a language?
The problem with defending the purity of the English language is that English is about as pure as a cribhouse whore. We don't just borrow words; on occasion, English has pursued other languages down alleyways to beat them unconscious and riffle their pockets for new vocabulary. -- James Nicoll
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.
"Grace" is a subjective term. In my mind, it looks just fine. Ruby & Python look weird and choppy.
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
PHP 5.5 may be great but a lot of people in the real world still don't use namespaces and other things introduced in 5.3.
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.
Right, PHP is used by lots of developers and some of them make bad decisions or have limited experience..
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.
Despite your sarcasm, that is a significant part of actually solving a problem: getting the solution into people's hands. Would you be very impressed with all the improvements if Ford's new line of 100% safe cars all cost millions of dollars?
I think it's important to remember that each programming language is good at different things. You wouldn't ordinarily try and build your blog with C++ just as you wouldn't ordinarily try and create a new operating system in JavaScript.
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.
There's a lot of noise about PHP becoming a better language by adding features. Isn't it well established that adding features to a dud product is not the path to a better one?
PHP is maturing but large user base and projects may slow the diffusion of idioms based on the new additions. Or maybe the next major releases of say joomla, wordpress and such have redesigned their core to leverage that. Maybe they'll follow the eclipse ecosystem-wide synchronisation of projects.
I often believe that these arguments over which language is better are a detriment to actually getting stuff done. But here I am commenting on stuff, rather than coding... so what does that say about me? :)
In my opinion, the only problem PHP suffers is that it's populated by many young, inexperienced developers. It's ease of use and low barrier of entry is a double-edged sword.
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.
>>> is that it's populated by many young, inexperienced developers.
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.
There are whole books written about how terrible JavaScript is, and yet it is one of the most popular languages today. People have learned to work around the quirks and develop best practices to avoid pitfalls.
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.
191 comments
[ 2.9 ms ] story [ 212 ms ] threadJust 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...
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.
[1] http://www.php-fig.org/
[2] https://github.com/php-fig/fig-standards
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"
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?
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."
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?
https://github.com/FrozenNode/Laravel-Administrator
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.
http://laravel.com/docs/facades
* 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!
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.
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.
[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()
>> 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.
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.
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.
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 :-)
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.
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.