PHP: Trying to fix the fractal
-
Just remembered^Wbeen reminded of another pain in the bum (though not as bad as some of those I already mentioned): error handling is inconsistent (throw an exception, trigger an error, or just return an out-of-band value and maybe set some state?) and insufficiently fine-grained (is the error triggered because of bad code or bad input?). See the bug report cited in the original post for the sort of thing that happens whenever something does get fixed.
-
@Anonymouse said:
@Watson said:
@The PHP manual said:
The PHP manual explicitly states - in the very part that you quoted - or at least very strongly suggests that PHP-arrays can be treated just like a (common) array, which would make most coders coming from other languages expect that it should behave just as joe.edwads described - but it doesn't.An array in PHP is actually an ordered map. A map is a type that associates values to keys. This type is optimized for several different uses; it can be treated as an array, list (vector), hash table (an implementation of a map), dictionary, collection, stack, queue, and probably more.
So the only people with any excuse for not expecting that the existence of $a[1] and $a[3] doesn't imply the existence of $a[2] are people who don't know what they are talking about.No, it explicitly states that it can be treated [i]as[/i] an array (in the same way that a milk jug can be used as a water container). If your paraphrase were correct, then you're talking about something that works [i]just like[/i] a queue (in that you can only append items to the tail and remove them from the head), and [i]just like[/i] a stack (in that you can only append items to the head and remove them from the head). That should have been a clue to you that you hadn't read carefully enough. If someone did remain in doubt - well, the page consists of more than one introductory paragraph, so it's not like they forgot to mention that keys aren't necessarily contiguous.
But, nevertheless,
-
-
@Severity One said:
Thinking about this a bit, I can see the user's point, although he's not making it very well. In certain contexts –for example, when filling in a tax form– it does actually make sense to consider an empty string as 0. The mistake that the user makes is to assume that it makes sense in all cases, and failing to see that his code relies on a bug, rather than a feature.
TRWTF is that it took the PHP authors 15 years to take care of that bug.
TRWTF, in my opinion, is that the user thinks the bug should be a feature, because he relies on it. That guy is obviously (albeit out of frustration) not thinking straight about what that function is actually supposed to do, as opposed to about what he is using it for.
-
@Watson said:
No, it explicitly states that it can be treated as an array
That's splitting hairs, right down to the subatomic level. What I am talking about is the impression that one gets when starting to use them, or even when actually bothering to read the documentation (ha, as if anyone does that, ever, at least before their code blows up in their faces!).They are called arrays everywhere, they use notation common for arrays in other languages, and the official documentations says there they can be treated as arrays - so isn't it reasonable that one might expect them to work like arrays? The documentation does not point out that there are subtle differences that might trip you up later. Principle of least surprise, remember?
-
@Anonymouse said:
What I am talking about is the impression that one gets when starting to use them, or even when actually bothering to read the documentation (ha, as if anyone does that, ever, at least before their code blows up in their faces!).
They are called arrays everywhere, they use notation common for arrays in other languages, and the official documentations says there they can be treated as arrays - so isn't it reasonable that one might expect them to work like arrays? The documentation does not point out that there are subtle differences that might trip you up later. Principle of least surprise, remember?
Do you have any examples of such "subtle differences"? There haven't been any mentioned so far in this thread.
The VERY FIRST SENTENCE says "An array in PHP is actually an ordered map." Is the solution to go through and replace every occurrence of "array" with "ordered map", and then deal with all those people who ask "but where are the arrays?" Which, not incidentally, do behave differently in different languages - an array in Java doesn't behave like an array in Python doesn't behave like an array in C - so anyone wandering into language A thinking that arrays there work exactly like (not merely "just like") those in language B deserves every laceration they get.
As for people who don't bother with manuals:
-
@Watson said:
Do you have any examples of such "subtle differences"? There haven't been any mentioned so far in this thread.
I was thinking of the one that joe pointed out, with the possiblity of intermediate array indexes being undefined. That would seem to be a surprising behavior (compared to what someone coming in from some other language might expect from something called an "array") that might be the source for strange bugs if not taken properly into account.
-
@Anonymouse said:
@Watson said:
Do you have any examples of such "subtle differences"? There haven't been any mentioned so far in this thread.
I was thinking of the one that joe pointed out, with the possiblity of intermediate array indexes being undefined. That would seem to be a surprising behavior (compared to what someone coming in from some other language might expect from something called an "array") that might be the source for strange bugs if not taken properly into account.No, I'm asking about the ones that - as you emphatically put it - "the documentation does not point out".
Because if any such things exist then they constitute bugs either in the implementation or in the documentation, and would need to be fixed (probably in the documentation, because people get all upset whenever the implementation changes to be less WTF-worthy).
I think if I were entering a new language I'd wonder to myself "do they have anything like arrays in here?" and poke around in the docs for something that looks like an array (I'll be poking around there anyway, if only for the sake of a 'Getting Started' guide). Fiddle with it a bit, see what the documentation says about it, compare what the documentation says with what is actually happening. Basically, try and learn what its arrays are like instead of just assuming that they're the exactly the same as every other array in every other language (which as I've already noted, is impossible).
-
@Watson said:
No, I'm asking about the ones that - as you emphatically put it - "the documentation does not point out".
I think I see the source of our disagreement. You are assuming the point of view of a smart programmer, who would actually try to inform himself about and understand the tools he is using.Whereas I am more thinking about the average programmer who is just interested in somehow getting his code to work without caring much about the whys or hows. Do you think that sort of programmer really has the due diligence to actually read the entire documentation, let alone the competence to understand the full implications of what he reads? You may call me jaded, from years of reading the stories on TDWTF, as well as personal experience with colleagues, but in my mind, that sort of guy will lightly skim over the docs (at best, and probably only after stuff breaks), picking up bits and pieces but missing the whole picture. He will read the "arrays can be treated as arrays", think to himself "okay, cool", form a mental model full of (wrong) assumptions and proceed to write code that will drive people like you and me up the walls if we are ever unlucky enough to find ourselves having to maintain it.
-
@Anonymouse said:
@Watson said:
No, I'm asking about the ones that - as you emphatically put it - "the documentation does not point out".
I think I see the source of our disagreement. You are assuming the point of view of a smart programmer, who would actually try to inform himself about and understand the tools he is using.Whereas I am more thinking about the average programmer who is just interested in somehow getting his code to work without caring much about the whys or hows. Do you think that sort of programmer really has the due diligence to actually read the entire documentation, let alone the competence to understand the full implications of what he reads? You may call me jaded, from years of reading the stories on TDWTF, as well as personal experience with colleagues, but in my mind, that sort of guy will lightly skim over the docs (at best, and probably only after stuff breaks), picking up bits and pieces but missing the whole picture. He will read the "arrays can be treated as arrays", think to himself "okay, cool", form a mental model full of (wrong) assumptions and proceed to write code that will drive people like you and me up the walls if we are ever unlucky enough to find ourselves having to maintain it.
And there we have what's probably the biggest problem with PHP: any shmuck can write a small PHP app that looks like it works fine if you haven't seen the code. If that's true then the whole argument boils down to whether that's a bad thing about PHP or about that shmuck.
-
@toon said:
@Anonymouse said:
I suspect this isn't just a PHP thing. The common fashion these days seems to be optimizing programming languages for ease of use by newbies. Those languages then attract the type of programmer who learns just enough to get work done.@Watson said:
No, I'm asking about the ones that - as you emphatically put it - "the documentation does not point out".
I think I see the source of our disagreement. You are assuming the point of view of a smart programmer, who would actually try to inform himself about and understand the tools he is using.Whereas I am more thinking about the average programmer who is just interested in somehow getting his code to work without caring much about the whys or hows. Do you think that sort of programmer really has the due diligence to actually read the entire documentation, let alone the competence to understand the full implications of what he reads? You may call me jaded, from years of reading the stories on TDWTF, as well as personal experience with colleagues, but in my mind, that sort of guy will lightly skim over the docs (at best, and probably only after stuff breaks), picking up bits and pieces but missing the whole picture. He will read the "arrays can be treated as arrays", think to himself "okay, cool", form a mental model full of (wrong) assumptions and proceed to write code that will drive people like you and me up the walls if we are ever unlucky enough to find ourselves having to maintain it.
And there we have what's probably the biggest problem with PHP: any shmuck can write a small PHP app that looks like it works fine if you haven't seen the code. If that's true then the whole argument boils down to whether that's a bad thing about PHP or about that shmuck.
-
@PedanticCurmudgeon said:
I suspect this isn't just a PHP thing. The common fashion these days seems to be optimizing programming languages for ease of use by newbies. Those languages then attract the type of programmer who learns just enough to get work done.
I was reminded today that you need to know, and care, about more than just programming in our business. For instance, I had no idea there was a leap second coming up at the end of the month, until this afternoon, when I found out about it by coincidence. I know a few apps of ours that might develop strange behavior or bugs because of that second (a WTF in itself to be sure). Leap seconds have nothing to do with programming, not in and of themselves. And you can definitely get work done without knowing about them. But it sure helps if you care about them...
-
@PedanticCurmudgeon said:
I suspect this isn't just a PHP thing. The common fashion these days seems to be optimizing programming languages for ease of use by newbies. Those languages then attract the type of programmer who learns just enough to get work done.
Seriously?
Not sure if serious...
-
Actually, it seems more accurate to say that the type of programmer who learns just enough to get work done complains very loudly about programming languages that aren't optimized for ease of use by newbies. Occasionally, language designers listen to them and hilarity ensues.
-
@PedanticCurmudgeon said:
Actually, it seems more accurate to say that the type of programmer who learns just enough to get work done complains very loudly about programming languages that aren't optimized for ease of use by newbies. Occasionally, language designers listen to them and hilarity ensues.
WTF are you on about. I still have no fucking clue. If this is a joke, it's either so arcane I don't get it, or so awful I don't recognize it as a joke.
Programming languages are "optimized for ease of use by newbies", what does that even mean? And Python is an example of one of these programming languages? WTF.
-
@toon said:
@PedanticCurmudgeon said:
I suspect this isn't just a PHP thing. The common fashion these days seems to be optimizing programming languages for ease of use by newbies. Those languages then attract the type of programmer who learns just enough to get work done.
I was reminded today that you need to know, and care, about more than just programming in our business. For instance, I had no idea there was a leap second coming up at the end of the month, until this afternoon, when I found out about it by coincidence. I know a few apps of ours that might develop strange behavior or bugs because of that second (a WTF in itself to be sure). Leap seconds have nothing to do with programming, not in and of themselves. And you can definitely get work done without knowing about them. But it sure helps if you care about them...
If a situation cannot be handled by the programming language you use, then this situation does not matter (to you).
-
@Speakerphone Dude said:
If a situation cannot be handled by the programming language you use, then this situation does not matter (to you).
Who says PHP can't handle leap seconds?
-
@toon said:
@Speakerphone Dude said:
If a situation cannot be handled by the programming language you use, then this situation does not matter (to you).
Who says PHP can't handle leap seconds?
The "situation" is not leap seconds. The "situation" is whatever happens because the leap seconds exist. If you have found a feature in PHP that allows the language to do something special when leap seconds are involved, please share.
-
@blakeyrat said:
WTF are you on about. I still have no fucking clue. If this is a joke, it's either so arcane I don't get it, or so awful I don't recognize it as a joke.
Some languages, Haskell and Lisp for example, have reputations for being difficult to learn. Other languages, Python and PHP for example, have reputations for being easy to learn. Which group do you think the type of programmer who only wants to learn the minimum would be more inclined to use?Programming languages are "optimized for ease of use by newbies", what does that even mean? And Python is an example of one of these programming languages? WTF.
-
@PedanticCurmudgeon said:
Some languages, Haskell and Lisp for example, have reputations for being difficult to learn. Other languages, Python and PHP for example, have reputations for being easy to learn. Which group do you think the type of programmer who only wants to learn the minimum would be more inclined to use?
Probably the latter, because you can actually get jobs working in those languages. But I still don't get what you're getting at here?
-
@blakeyrat said:
@PedanticCurmudgeon said:
Toon raised a rhetorical question:Some languages, Haskell and Lisp for example, have reputations for being difficult to learn. Other languages, Python and PHP for example, have reputations for being easy to learn. Which group do you think the type of programmer who only wants to learn the minimum would be more inclined to use?
Probably the latter, because you can actually get jobs working in those languages. But I still don't get what you're getting at here?
@toon said:And there we have what's probably the biggest problem with PHP: any shmuck can write a small PHP app that looks like it works fine if you haven't seen the code. If that's true then the whole argument boils down to whether that's a bad thing about PHP or about that shmuck.
My answer was that the problem isn't restricted to PHP. I left the obvious inference that the problem must therefore be the schmucks unstated. Basically, if PHP didn't exist, the schmucks would perform their schmuckery in Python or some other easy-to-learn language.
-
@PedanticCurmudgeon said:
@blakeyrat said:
@PedanticCurmudgeon said:
Toon raised a rhetorical question:Some languages, Haskell and Lisp for example, have reputations for being difficult to learn. Other languages, Python and PHP for example, have reputations for being easy to learn. Which group do you think the type of programmer who only wants to learn the minimum would be more inclined to use?
Probably the latter, because you can actually get jobs working in those languages. But I still don't get what you're getting at here?
@toon said:And there we have what's probably the biggest problem with PHP: any shmuck can write a small PHP app that looks like it works fine if you haven't seen the code. If that's true then the whole argument boils down to whether that's a bad thing about PHP or about that shmuck.
My answer was that the problem isn't restricted to PHP. I left the obvious inference that the problem must therefore be the schmucks unstated. Basically, if PHP didn't exist, the schmucks would perform their schmuckery in Python or some other easy-to-learn language.Thank God for PHP. Otherwise we would have the same exact discussion but featuring VB, and after 15+ years it was becoming tedious.
-
@PedanticCurmudgeon said:
My answer was that the problem isn't restricted to PHP. I left the obvious inference that the problem must therefore be the schmucks unstated. Basically, if PHP didn't exist, the schmucks would perform their schmuckery in Python or some other easy-to-learn language.
Ok, I think I'm starting to get your pattern of thinking, which is insane and wrong and here's why:
1) Popular languages are easy-to-learn, unpopular ones aren't. LISP is hard-to-learn because nobody fucking uses it, there's no experts on it, there's no classes on it, there's no job listings requiring it to create an ecosystem of training for it.
2) The ease-of-learning of a language (defined, mostly, by popularity) has absolutely nothing to do with the quality of programming from that language. Example: PHP apps generally suck, right? But C# apps, C# being a language much easier-to-learn than PHP, generally do not.
3) Nobody's writing languages to be easy for "newbs" (possible exception: Kodu), that's a ridiculous and borderline crazy assertion. The trend in language design has been to:
a) Remove pointless boilerplate
b) Make the language to be internally-consistent ("Principle of least surprise", and here's where PHP fails HARD)
c) Encourage code that is readable over a long period of time (that is, encourage developers to write code other developers will understand easily)
with the unstated-but-obvious goal of: making writing the code take less time so developers can spend more time on the things about their application that actually fucking matter like, to give my usual example, fucking usability. (Incidentally, here is where the unpopular languages fail-- you can't write a usable application in goddamned Go or LIST because there's no tool support, there's no tool support because only uber-nerds look into the language and uber-nerds don't understand shit about actually developing software for human beings to use.)Anyway, one of those three points you're confusing for "make it easy for newbs". I dunno which.
-
@blakeyrat said:
Ok, I think I'm starting to get your pattern of thinking...
No, you aren't. However, at least two people understood what I was getting at, so I guess you'll just have to be left in the dark on this one.
-
@blakeyrat said:
1) Popular languages are easy-to-learn, unpopular ones aren't. LISP is hard-to-learn because nobody fucking uses it, there's no experts on it, there's no classes on it, there's no job listings requiring it to create an ecosystem of training for it.
You've got that completely backwards. Nobody uses LISP because it is hard to learn. Why it's hard to learn is a completely different issue: because it's very hard to read, as in:
@blakeyrat said:
c) Encourage code that is readable over a long period of time (that is, encourage developers to write code other developers will understand easily)
And it's so hard to read because of two points that Lisp proponents call important features, which means it's not likely to change anytime soon:
1) Lack of syntax. Yes, this is wonderous and magical and amazing because... erm... because... *waves hands* MACROS! Yeah, that's it, and if we say it loud enough and often enough, someone might listen! But it also means a distinct lack of easily-understandable visual cues. For example, in Python you can easily tell what's inside a particular block and what isn't. But in Lisp, you have to count parens, and all those nested parentheses can get pretty deeply-nested.
2) Dynamic typing. There is no way to tell what any given variable is, what kind of data it contains, and what operations on it make sense, without reading a ton of other code for context. And unlike point #1, you can't even get tooling to help you with this one, because the type information isn't there for the tools either. This makes any code written by someone else (including yourself 6+ months ago) very difficult to figure out.
-
@Mason Wheeler said:
The syntax was never a problem for me; emacs indents the code for you so you can see structure that way. Item 2 was a big issue whenever what I was writing got over a few hundred lines. Then again, I had the same problem with Python. I guess some people do better with static typing.1) Lack of syntax. Yes, this is wonderous and magical and amazing because... erm... because... waves hands MACROS! Yeah, that's it, and if we say it loud enough and often enough, someone might listen! But it also means a distinct lack of easily-understandable visual cues. For example, in Python you can easily tell what's inside a particular block and what isn't. But in Lisp, you have to count parens, and all those nested parentheses can get pretty deeply-nested.
2) Dynamic typing. There is no way to tell what any given variable is, what kind of data it contains, and what operations on it make sense, without reading a ton of other code for context. And unlike point #1, you can't even get tooling to help you with this one, because the type information isn't there for the tools either. This makes any code written by someone else (including yourself 6+ months ago) very difficult to figure out.
