Hacker News Reader

Comment by jmadsen | Hacker News Reader

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

View on HN

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.

Deprecating unsafe/"bad" features is not "in PHP's blood" ?

Have you even read a PHP changelog recently?

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.

Radically overhaul how variables work? Im not sure i even understand what that is supposed to achieve? Make them not variable any more?

You're suggesting self-proclaimed radical changes but not giving any information about the actual advantages?

Ah, sorry, some actual context might be helpful.

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. :)

yes reading from undeclared php variables causes an error, assuming you haven't silenced using @ or set php to ignore notices.

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.

> 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.

I can't tell if this is a joke or not

Oh no, I forgot the variable placement in a function, this language sucks! ಠ_ಠ

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.

"Modern tools" what is PHP the rock wheel or something? Get over yourself.

It is an old language, which keeps getting bent to fit the new development practices. Of course it's not just a rock wheel, it has rubber around it.

an "old" language? compared to what?

Ruby appeared in 1995, the same as PHP

JavaScript appeared in 1995, the same as PHP

Python appeared in 1991, four years earlier

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

He's now just backpedaling. Best to ignore it and move on.

He brought up compatibility because compatibility and novelty are often opposites.

"Old" as in "it didn't age well".

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.

Because you don't always get to use an IDE and want your code to be readable? Just saying.

What do you mean "don't always get to use an IDE"?

Do you work for north koreans or something?

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.

Changing language because your toolset is poor? no thanks.

I'd agree to disagree at this point.

So how about PHP having two separate error handling mechanisms for no good reason?

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.

>>> while PHP and Ruby pretty much do the same thing

Says who?

>>> one is just prettier and streamlined.

By which objective measure of "prettier" and "streamlined"?

Says who?

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.

I have distinct feeling that some people think they have an objective definition of pretty (and of course it completely fits their favorite tool).

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.

What in particular makes PHP ugly, compared to JS (or Java or C)?

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.

If you think other languages are different, you didn't learn those languages thoroughly enough. So you just are saying people suck. Well, sure, so?..

"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

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.

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.

Ford sucks because with the improvements and better safety requirements to the car industry people are still driving older cars!

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?

So it's Ford's fault that people aren't buying new cars? Weird.

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.

The only feature I miss in PHP is un-gotcha-ness. Does it have that yet?

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.

> be reborn as your favorite whatever

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.

Why do you care about 90% "silly features"? Don't like them, don't use them.

Reply on news.ycombinator.com