I don't think that a concise method of working with arrays should be thought of as syntactic sugar, not if you mean it in a pejorative way.
I found array_map, array_filter, array_key_exists, array_this, array_that painful to write, but never felt that I was gaining any sort of readability for it.
No I meant "syntactic sugar" in a good way, i didnt realise it was a pejorative.
I mean it as per the definition on wikipedia:
Syntactic sugar is a computer science term that refers to syntax within a programming language that is designed to make things easier to read or to express, while alternative ways of expressing them exist.
It is not generally perjorative. Some people interpret it as automatically perjorative, feeling that any syntactic sugar must necessarily carry costs in excess of benefits, but they are in the minority. Sizable minority, but minority.
Concentrations of people who dislike all syntax sugar can be found in the Forth community and concatenative languages in general, Lisp, and to a lesser extent, in the Haskell community. People who think syntax sugar is the answer to everything can be found in the Perl 5 community, and Perl 6 is arguably syntax sugar spun into cotton candy, hardened, and used to build a glorious gossamer castle in the sky, which they are currently working on landing. I have taken this metaphor too far.
The pro/cons are arguments extracted from the mailing list. So the guys on the pro side said it was readable, the guys on the contra side said unreadable.
Considering how widely taught (and self-taught) PHP is, I think that's pretty important, if only from a business perspective―if people don't learn your language, they don't buy your licensed books, and they don't need your technical support because they never built anything with it.
Well, python or javascript does not suffer from this, does it? And, I cant, actually, think of any case where code search would require "Array" term.
On the second thought - if PHP would at last consider converting or storing everyhting as an object ("".length or [].walk()), this would cause a problem. Still, see my first sentence.
Not being SEO friendly is an interesting argument. While learning Python, when things like list comprehensions came up in code I was reading, it was very hard for me to figure out how it worked when I couldn't Google the syntax.
I've always wanted a search engine that is optimized for searching for code embedded in web pages. AFAIK google code search isn't really an option because it only searches through code, not through blog posts, stack overflow, and other pages with code in them.
As far as language design goes though, I'd rather use a language that's optimized for writing code than for searching for it :).
Why try to make PHP more readable? Just use another language.
PHP, like C++, is a big industry dinosaur that can't and won't change.
In my opinion, the best think you could do is create a new language which compiles to PHP. I.e. A coffeescript for PHP. You don't have to "vote" and get stupid arguments against; you don't have to be backward compatible; and you only have great programmers in that project since crappy ones will just continue to use their 1500 lines unmaintainable functions anyway.
But why not make it more readable? The patch exists - all it would take is for it to be accepted.
And there are a ton of people who can't justify the switching costs of moving to a different language. And true, a lot of us aren't great programmers. So?
Better tools help. And it's perfectly okay to build and improve tools that regular people will use. Even if they won't be creating the Mona Webapp. ;)
And it's perfectly okay to build and improve tools that regular people will use.
It is, unfortunately PHP resists changes that most of the rest of us consider improvements. I think at this point we might be better served by putting our efforts in to replacing PHP rather than improving it. The replacement need not be the ultimate web language, but should try to be a good language while maintaining a low barrier to entry.
This does not seem reasonable. I mean that literally -- this feels more like a choice driven by culture than by reason.
The cons seem nowhere near strong enough to counter the fact that the overwhelming majority of users want this syntax, and have been asking for it for years.
I catch myself feeling that way, too, but it is uncharitable and inaccurate. They do work a lot of work on developing the language. The issue is that sometimes their idea of what is should be differs from the idea that most people have.
I don't think it's possible to be too uncharitable about the developers of PHP. Courtesy demands that we give them the benefit of the doubt; but by this stage there is very little doubt left, so very little benefit as well.
the language they built and let everyone in the world use for free powers sites from wikileaks to whitehouse.gov, and its simplicity allowed a lot of non-programmers to write working code and sometimes even start new careers. so it is possible to be too uncharitable about them.
that decision, though, is unfortunate IMHO. esp seeing that the userland votes are overwhelmingly pro while the devs are con.
If courtesy means giving undeserved benefit of the doubt, I'm all for discourtesy. This is about rational discourse.
The statement that "It's like they don't even _want_ to fix the language" is inaccurate. It does not relate to the state of things in the real world.
Accusing the developers of some warped intent to keep it in a broken state is an understandable expression of frustration, but it does nothing to advance our discussion and contributes to a misunderstanding of the situation.
I still hold a grudge against them for disabling short tags by default.
Who decided that "<?php echo $variable;?>" is better than "<?=$variable ?>". I think one of their main arguments was that it could conflict with XML / XHTML parsers, but the people who want to parse php files using XHTML parsers are probably in the minority.
Whenever I stop coding PHP for a while and return to it, the lack of short array syntax always blows up in my face. I waste a lot of time debugging to just find that arrays need to be initialised with array().
It's been a long time since I did any PHP, but are trailing commas illegal? Normally, it seems like languages follow one of these two patterns, depending on whether their syntax allows extraneous commas or not:
foo = [
'first',
'second',
'third',
]
or
foo = [ 'first'
, 'second'
, 'third'
]
The difference between those two examples and yours being that when you want to add a new entry, you only have to edit the line of the entry, rather than having to edit the line before the entry (to put in the comma) as well as the line that you care about. Just an idle question, really.
This is why I stopped reading the dev mailing list. It was too frustrating to see (IMO) awesome features and suggestions constantly swatted down for (again, IMO) stupid reasons. Not searchable through search engines? Give me a break! I didn't know I was supposed to be writing code for Google. There are _so many_ higher priorities.
I think PHP is going to remain all but stagnant until there is a sea change in the core developers. I'm not sure what their true motives are... laziness? underlying dislike for the language? Whatever it is, all they seem to do is swat down every request, even when (as is the case here) the users are _begging_ for it.
It's like if they can come up with any reason at all not to do it, then they don't. "We already use square brackets for other stuff." Give me a f--king break.
It's being brought forth again for 5.4, and really pushed. Their is a lot of momentum from the community, and even those who voted against it before are changing their mind.
I think the "vote" recorded in the link is from a long time ago. Looking at the php.internals mailing list from today, this is what Rasmus is saying:
"Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.
Whether we should extend that to also add a short object syntax is a
secondary question." (http://news.php.net/php.internals/52597)
I've just spent a while reading the most recent of the discussion threads linked from there, and they're just further examples of the hostile and insular communities that form around far too many open source projects. Frustrating to read, painful to participate in.
I would give up hope for the ability to have a short syntax for arrays (or lots of other syntactical pleasantries) if the core team would please finally implement named arguments.
The most common way that we get to implement (hack) it now is by using an associative array, which then hides parameters in the implementation of the method as opposed to exposing it in the interface which helps both with reading someone elses code as well as provides for parameter initialization and type hinting (which assoc arrays remove).
I agree with you about argument inconsistencies, and named parameters would help with that, but it even goes beyond that, e.g. how many times have you seen this:
function foo($bar = true, $baz = 5, $qux = "change me"){ ... }
foo(true,5,"this is what i wanted to change");
Few people asked for, or even wanted GOTO, yet that seemed to make it through with flying colors. When people would argue against it, the rationale was "well, you don't have to use it!"
Why does the same criteria not apply to short array syntax? If you don't want to use it, don't use it, but hundreds of thousands of other people likely do want it.
FWIW, I first remember hearing about this in 2003/2004, and at that time I was against it for most of the same reasons I've read in opposition to adding it. Working outside of PHP for some time, I've come to realize the shortsightedness I labored under, and would fully love to have this.
I'm not 100% sure the votes on that page are from May 2011 - it's hard to tell for sure.
goto is a limited goto, and the reasoning for it's inclusion makes sense when you consider the other forms of limited goto already in place (breaks, cases, try/catches). It's not an unlimited goto.
The wiki page would have diffused this entire post if it had the dates of the votes on it :)
I understand GOTO, but the reaction to people who thought it was a bad idea was "don't use it!", ignoring the fact that whether we use it or not, we have to deal with other peoples' code that do use it.
It was me who wrote that proposal 3y ago. Everyone who is still doing PHP, do whatever you want. Everyone who had left for Ruby or JS - let them - they just don't want.
88 comments
[ 3.8 ms ] story [ 149 ms ] threadKinda strange that they have both readable and unreadable listed as both pro and con...
I found array_map, array_filter, array_key_exists, array_this, array_that painful to write, but never felt that I was gaining any sort of readability for it.
I mean it as per the definition on wikipedia:
Concentrations of people who dislike all syntax sugar can be found in the Forth community and concatenative languages in general, Lisp, and to a lesser extent, in the Haskell community. People who think syntax sugar is the answer to everything can be found in the Perl 5 community, and Perl 6 is arguably syntax sugar spun into cotton candy, hardened, and used to build a glorious gossamer castle in the sky, which they are currently working on landing. I have taken this metaphor too far.
$newArray = $array->map("function_name");
Not gonna happen, but would be nice. Any extensions doing this?
I think it would have been a nice addition...
-edit- beaten to the punch on that one!
Considering how widely taught (and self-taught) PHP is, I think that's pretty important, if only from a business perspective―if people don't learn your language, they don't buy your licensed books, and they don't need your technical support because they never built anything with it.
Oh, wait...
On the second thought - if PHP would at last consider converting or storing everyhting as an object ("".length or [].walk()), this would cause a problem. Still, see my first sentence.
As far as language design goes though, I'd rather use a language that's optimized for writing code than for searching for it :).
(The "true" causes the value to be returned rather than printed, obviously.)
The topic was then resurrected about implementing in the 5.4 release and the objections didn't seem to be as strong this time around.
So the rejected status doesn't mean that it won't happen in 5.4 just that that was the previous status of the changes.
PHP, like C++, is a big industry dinosaur that can't and won't change.
In my opinion, the best think you could do is create a new language which compiles to PHP. I.e. A coffeescript for PHP. You don't have to "vote" and get stupid arguments against; you don't have to be backward compatible; and you only have great programmers in that project since crappy ones will just continue to use their 1500 lines unmaintainable functions anyway.
And there are a ton of people who can't justify the switching costs of moving to a different language. And true, a lot of us aren't great programmers. So?
Better tools help. And it's perfectly okay to build and improve tools that regular people will use. Even if they won't be creating the Mona Webapp. ;)
It is, unfortunately PHP resists changes that most of the rest of us consider improvements. I think at this point we might be better served by putting our efforts in to replacing PHP rather than improving it. The replacement need not be the ultimate web language, but should try to be a good language while maintaining a low barrier to entry.
Make this happen please. I can't think of a more deserving language and it'd make my day job a lot nicer.
http://pypi.python.org/pypi/hotpotato
The cons seem nowhere near strong enough to counter the fact that the overwhelming majority of users want this syntax, and have been asking for it for years.
that decision, though, is unfortunate IMHO. esp seeing that the userland votes are overwhelmingly pro while the devs are con.
The statement that "It's like they don't even _want_ to fix the language" is inaccurate. It does not relate to the state of things in the real world.
Accusing the developers of some warped intent to keep it in a broken state is an understandable expression of frustration, but it does nothing to advance our discussion and contributes to a misunderstanding of the situation.
Who decided that "<?php echo $variable;?>" is better than "<?=$variable ?>". I think one of their main arguments was that it could conflict with XML / XHTML parsers, but the people who want to parse php files using XHTML parsers are probably in the minority.
Which is why it's being brought up again for 5.4, since this vote took place in 2008.
I really don't see the issue here.
$foo = { bar: TRUE, baz: 'socks' };
where keys are unquoted. The less typing the better.
$keyName = "bar"; $array = array($keyName => "baz");
So in that instance it makes sense to force people to quote their keys. Also, bar or baz could be constants.
http://www.json.org/
I know some browsers allow it, but it's not true JSON.
EDIT: pull unnecessary commentary
$a = array(1,2,3,); works just fine.
http://www.cacert.org/index.php?id=3
I think PHP is going to remain all but stagnant until there is a sea change in the core developers. I'm not sure what their true motives are... laziness? underlying dislike for the language? Whatever it is, all they seem to do is swat down every request, even when (as is the case here) the users are _begging_ for it.
It's like if they can come up with any reason at all not to do it, then they don't. "We already use square brackets for other stuff." Give me a f--king break.
It's a shame that PHP does not get better as a language, as from the point of view of deployment and "get things done now" is great.
It's being brought forth again for 5.4, and really pushed. Their is a lot of momentum from the community, and even those who voted against it before are changing their mind.
"Other than a couple of grumpy old-timers, I think we are in agreement that we should add a short array syntax. Whether we should extend that to also add a short object syntax is a secondary question." (http://news.php.net/php.internals/52597)
http://markmail.org/message/4brot4f6kthjfzse
edit: ahh, found it. Knew what it was, but not what it was called: http://en.wikipedia.org/wiki/Keyword_argument
Would definitely be a solution to PHP's ridiculous argument ordering inconsistencies.
The most common way that we get to implement (hack) it now is by using an associative array, which then hides parameters in the implementation of the method as opposed to exposing it in the interface which helps both with reading someone elses code as well as provides for parameter initialization and type hinting (which assoc arrays remove).
I agree with you about argument inconsistencies, and named parameters would help with that, but it even goes beyond that, e.g. how many times have you seen this:
when all you should have to do is:Why does the same criteria not apply to short array syntax? If you don't want to use it, don't use it, but hundreds of thousands of other people likely do want it.
FWIW, I first remember hearing about this in 2003/2004, and at that time I was against it for most of the same reasons I've read in opposition to adding it. Working outside of PHP for some time, I've come to realize the shortsightedness I labored under, and would fully love to have this.
I'm not 100% sure the votes on that page are from May 2011 - it's hard to tell for sure.
goto is a limited goto, and the reasoning for it's inclusion makes sense when you consider the other forms of limited goto already in place (breaks, cases, try/catches). It's not an unlimited goto.
I understand GOTO, but the reaction to people who thought it was a bad idea was "don't use it!", ignoring the fact that whether we use it or not, we have to deal with other peoples' code that do use it.
The people shouting "don't use it!" are thinking of a limitless goto. It's a shame, but not surprising really.
Cons: Unreadable
What does that even mean?