6 ms·

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

by camus 13y ago

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

smsm42 13y ago
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.
- klibertp 13y ago
  > 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...
  - krapp 13y ago
    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.
  - smsm42 13y ago
    >>> 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.
    - klibertp 13y ago
      > 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.
rorrr2 13y ago
Why do you care about 90% "silly features"? Don't like them, don't use them.

by camus 13y ago

smsm42 13y ago

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.

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

rorrr2 13y ago

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