4 ms·

> 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

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

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

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

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