4 ms·

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

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

smsm42 13y ago
>>> 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.

smsm42 13y ago

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