ManiacDan

I still gave him a full point because you can't argue with the basic statement: The error condition is also valid output. The fact that the programmer should know better doesn't change the validity of his statement. Reported? I hate it too, I was mimicking his style. He's synergized to the cloud, and eschews boilerplate for more streamlined antipatterns and whatnot.

At least I wrote it during normal business hours. Not like last time, when I argued about it on reddit until like 3am.

Thanks. I didn't even remember we had a misc forum. I x-posted to devshed under the generic "main PHP" forum.

Devshed User Jacques' signature has been recently changed to: As I've seen this article a number of times, I'd like to go through it to see what everyone has to say on the subject. Warning: This is just stupidly, ludicrously long. it takes an existing 5-page article and tears it apart nearly sentence-by-sentence. First, let me say that PHP isn't perfect. There's a lot of weirdness to it, a lot of examples of a language that grew organically by a large multinational team instead of being designed by a small committee of English-speaking developers. But that doesn't mean it's bad design, just that there's quirks, like any well used system. Now, onto the article itself. We're first presented with his toolbox analogy. This ridiculous piece of prose seems to be insinuating that the basic control structures of PHP are somehow non-standard and don't work like every other language. A hammer with a peen on both ends? A screwdriver which only works with specialty screws? How is this an analogy for the most popular web language in the world? He goes on to say that the builders who use these tools make things that don't work and fall down at the slighest provocation. Now, having read this before, I know that he goes into defense mode over this statement later, but I'll go ahead and attack it now: Show me the faults in facebook. Show me where wikipedia falls down when you touch it. Find the design flaws in vbulletin, wordpress, or any of the other toolsets that would be at all analogous to a house "where every room is a pentagon and the roof is upside-down. And you knock on the front door and it just collapses inwards." Stance After his analogy, we get his stances. These are almost all wrong, and illustrate his basic misunderstanding of languages in general. He believes languages shoudld be: Predictable - The author states that it's the language's responsibility to be understood by everyone who uses it, rather than the builder's responsibility to understand their tools. He doesn't understand why PHP does something, so instead of investigating and learning more, he declares PHP "broken" and "badly designed." This is a recurring theme in the article. Much of his problems with PHP stem from him not understanding symbol tables or loosely typed languages. Just look at his list of "surprises": mysql_real_escape_string? OH MY GOD! SHOCKING! What the hell is he talking about? And E_ALL? How is a constant name (which resolves to -1 anyway) a "surprise"? The list of error-level constants is in the manual. they all begin with E_ and then give what they describe. E_ALL is all. E_STRICT is strict. E_WARNING is warings. This is surprising? This guy should stay away from haunted houses. Consistent - Apparently things that look the same should work the same in a programming language? And if you know one part you should be able to understand other parts? This appears to be a dig at PHP's ecclectic naming conventions, and I will certainly give him that. htmlentities should have underscores like its counterpart, html_entity_decode. Of course, the counterpart of every function is in that function's manual page, but "the manual is right there and it's free and it's integrated into the free IDEs" still isn't an excuse. The language needs to be cleaned up from a naming perspective. He gets one point. Concise - He makes statements about "boilerplate" a number of times, but never defines the term or tells us what he's talking about. PHP is very concise. It includes time-saving functions like usort(), file_get_contents(), and other functions which in C++ would take pages of code. Of course, it also requires error checking, which seems to be what he's complaining about. He lists error-checking as boilerplate. I don't know how Python handles it, but generally as a programmer I'd like to know if a file operation failed. His point here seems to be that low-level functions return false instead of throwing an exception, which is honestly a holdover from when PHP was young and didn't have exceptions. However, which is more boilerplate: if ( !( $file = fopen('file.txt', 'w') ) ) or a try-catch block? Reliable - This, again, is him assuming that it's the language's responsibility to be understood, rather than his responsibility to understand it. He goes into what he considers "gotcha" events later in the article, but (spoiler alert) they all stem from his fundamental misunderstanding of the language. You can tell because his two examples perfectly illustrate his misunderstanding. The == operator is listed as "flaky." The == operator is the core of loosely typed languages, and is immensely powerful. He thinks it's flaky because he can't wrap his brain around loose comparisons. His second example is a by-ref loop, something which exists in all programming languages. The only "gotcha" here is that his understanding of the way variables work in this language is simply wrong. Debuggable - Now this I'll give him. PHP's error handling is atrocious. I mean, look at the errors some of these new users are getting on PHPFreaks. Who can solve any problem when given just the error type, line number, function name, data type, prose description of the error, and potential fix? That's ridiculous! [/sarcasm] Maybe Python's error handling is much more robust than I remember, but PHP's has thus far been fine for me. Better than the error handling of things like Oracle, with 'cannot bind' being the only error I got yesterday. His examples require a stack trace, which I guess could be handy some of the time, but honestly I've rarely used the stack traces we build into our error-handling at work (which is easily overridden in the PHP core with a set_error_handler call) Arguments Now, our author goes into a list of arguments he automatically discards. Luckily, my argument of "you don't understand PHP and it's not PHP's job to get into your brain and force you to understand things you choose not to" isn't on the list. He does say that it's not his responsibility to "memorize a thousand strange exceptions." I agree with him on that, strpos should be renamed. However, it is his responsibility to come to an understanding of how programming languages work, and he has failed to do so. He also uses a wonderful straw man with "you should just use C if PHP handles 5% of its operations the way C does." Just because fopen returns false in C and in PHP doesn't mean PHP is a net loss. Finally, his argument of "the largest and most popular websites in the world, designed and written by the smartest programmers in the world, don't prove anything" is laughable. The conscious choices of almost every single web engineering team worth a damn do, in fact, count as proof that the tool they've chosen is worthwhile. (He also says not to argue with him at all, because he's just stomping his little feet and nothing will change his mind. I'm writing this for the PHPFreaks community, not this guy who can't figure out how PHP works.) Philosophy PHP was designed to be easy to understand, because at the time the thought of full-featured web applications was silly. An item's source doesn't discredit what it's become. What if someone told you "America was founded to be a colony (and, reading between the lines, not a country); it has not well escaped its roots. This is why I believe nobody should take America seriously as a country." Stupid, right? Good, glad we agree. MY GOD! HOW LUDICROUS! PHP is a web language with very little ability to recover from a crash the way you would in a desktop environment. It will keep doing its best and instead of a blank screen (or a blue one) maybe a bad programmer will get her site's navigation bar with some errors underneath it. But she WILL get something. The fact that PHP doesn't crash and burn as easily as the other languages doesn't have me crying myself to sleep at night. Yes, we know. He still has one point. So wait...you're telling me...different languages can build on each other, but an expert in one isn't automatically an expert in the other? Alert NASA, we have a breakthrough in human understanding. Languages are different. That's the point of making new languages. Sorry if Perl's regex format is confusing to a C guru. Perhaps he should learn Perl before complaining that the syntax of a language he doesn't know is confusing. This is the closest he comes to outright saying "I don't understand it and therefore it's wrong." If you want to understand how weak typing conversions work, you could look in the manual for the chart, or you could read my article on it. From the man who complained about the syntax of arrays, namespaces, and type conversions literally 2 sentences prior. Code example: fopen First of all, let me start by saying that when he said the line he discovered was "somewhere in the manual," it was deep into the manual entry for complex system-level error-handling functions and was specifically designed to suppress errors in a weird way so that you could see how error-screaming works. The fact that he pulled this frankly BS example out of a manual entry on weird and complex error handling shows just how hard he was reaching to make a point, but since his misunderstanding of PHP is well illustrated here I'll continue. Except the docs DO say what happens when the function fopen fails: it returns false. It's in a nice blue box labeled "returns." Can't miss it. Line-level error suppression is a powerful feature, I'm glad to use a language which supports it. System-level forcing of all errors is another powerful feature, I'm glad I don't have to go find ever @ sign in my code when I'm debugging something weird. I'm beginning to think he's never used a programming language at all. Is it just me, or should every web language have server-level error reporting configuration? What does Python do? Just spit all errors to the screen no matter what? If you want to log to a file, you have to do that by hand for every error? That sounds awful. Or he's full of it. Back to individual complaints Server-level configurations are pretty handy and remove a lot of boilerplate, don't you think? Good thing removing boilerplate was one of his biggest criteria back at the beginning. Shame the manual on that function isn't 4 pages with explanations and usage examples or he might learn something. It's purely a web language, and nothing else. Websites don't need threads, because if they take longer than a second to run they've failed. Again, fundamental lack of understanding. He gets another point here, json_decode really should throw an exception. Though to be fair, if I ever get a json object which resolves to null, I'm going to handle it as an error regardless. Once again, if this person would take 10 minutes to attempt to understand loosely typed languages, this would all make sense. These functions return the index of the item found. if no item is found, they return false. That sounds really powerful, and I'm not sure why it's even a complaint. Luckily for the reader, he goes on to explain his ignorance: C and Python crash fatally, potentially destroying the memory space of other programs. Got it. So basically, if you don't include the right boilerplate around other languages, they fatally crash and destroy their state, potentially also destroying neighboring programs in memory. However, if you do the same erroneous code in PHP, it continues to work with slightly unexpected results. Tell me again why "keeps working" is a problem? Plus, for what might be the 10th time, he just plain doesn't understand loosely typed languages. Yes, false == zero. That's actually an incredibly powerful feature of the language. The boilerplate he's comparing about isn't exactly onerous either. Look, here it is: "!== false". Oh man, look out. That nearly broke my fingers I typed for so long. And they're all stupid heads and not invited to my birthday party. I love how he "had to fit in" an ad hominem attack against an entire community of developers. He even states further up in the article that facebook and wikipedia run PHP, and still manages to claim that those people are amateurs. "Back to the facts" (and by "facts" we mean "opinions borne of fundamental misunderstandings") Blah blah doesn't understand loosely typed blah. Quite literally damned if you do, damned if you don't. He simultaneously complains about PHP doing something, then not doing that same thing. I really should make a hotkey for "he doesn't understand loosely typed languages." PHP has strict function scope, and globals aren't automatically imported for reading and writing. His complaint seems to be that all globals aren't read-only inside all functions, which I personally think is confusing if it's done that way. Why should I be able to read $foo but not write to it? Doesn't that seem more confusing? His second fundamental misunderstanding finally rears its head here: Symbol tables. PHP doesn't use variables like other languages, it uses symbol tables. PHP does in fact have references, and pass-by-identity (objects are always passed by reference). I'm willing to grant him another point here (which makes three). If you, for instance, make $a a reference to the third item in array $b, then any modifications to $a modify the inner structure of $b, though $a still looks like a stand-alone variable. Perhaps another symbol would be good, but then you get into the problem of perl, where $a and #a and &a are all confusing and conflicting things. Difficult problem to solve, but most programmers just don't use references unless they need them. "PHP is too confusing, I have to memorize so many things! Waaaaaah! In addition, there's aliases for things so if I forget and use the wrong one it will still work! PHP IS AWFUL!!" "I don't read my log files, what kind of programmer would ever use error logs to debug? That's stupid! My website should just die with a white screen and a 'Sorry!' message whenever there's an error so I know to go try to remember where I put the error logs" As stated above, E_STRICT is an error-level constant (hence the E_) and is well defined in the manual. The things he listed as "silent" are not errors in the least, they're all valid PHP operations. He seems to think E_STRICT should mean "work more like another programming language." Probably because he doesn't understand PHP. Are there interpreted languages which throw in-application exceptions instead of language-level errors when they encounter fatal or parse errors? I don't think there are, I think the author doesn't understand interpreted languages vs compiled ones. The one example he has of this shows someone attempting to create an anonymous (unreferenced) array, put a variable in it, and then have it immediately destroyed. Not sure why that's even something someone would do, but...err...you got me. OO Anyone else feel like scrolling up to where he complains about function names being case-insensitive? No? Our dear author has not yet discovered the simplicity of $foo->bar. Either that or he has absolutely no understanding of how objects work in ANY language. Aside from demonstrating the "var" syntax (deprecated over a decade ago), this doesn't understand the complexities of designing a real system in PHP. Still not getting why he complains about additional functionality he doesn't even have to use. So you can foreach over an obect to get its public variables (or, if it implements arrayaccess, some other variable of the author's choosing). If you don't like that, don't use it. It's like saying "unlike C, Python allows me to have tuples." So? None of this makes any sense at all. I'm willing to give him the benefit of the doubt and assume he hit his head or something. Wow, that's an excellent point. I'm glad we're talking about a compiled language and not, for instance, PHP. Arrays Once again, who wants to volunteer to scroll up to where he complained about the shortcut array syntax? It's like this article was written in 2004, and then he updated it with more complaints, many of the complaints being about the fixes to his previous complaints. It's like the room is filthy, and the maid used floor polish that smells too strongly. One or the other. Because it's a loosely typed language perhaps? Because it's possible to use a variable without defining it, even constants, and therefore an unquoted bare string literal is assumed to be an undefined constant? Becuase you don't understand loosely typed languages? Missing Features So "remember to use htmlspecialchars" doesn't count, but "remember to use marksupsafe" does? Gotcha. Good to know that the criteria for language functionality can just change mid-sentence. Because his last example was a function call you had to wrap arounde every string, I'm going to go ahead and assume that's what he'd use to "prove" this point as well, if such a library is even available. There's no standard database API. Except for the standard one. But that one doesn't count because deep down below where you can see it, it doesn't call the same functions for each database. This one I actually know nothing about. Do other languages have built-in user authentication which can work as a login system? So if I want to write a web login system in Python, there's a built-in language core module for that? Security Again, I'm going to have to ask how Python does that. Does Python automatically sanitize plaintext output? How would you print a <script> tag in python if that's the case? Or is this, like most of his complaints, just how languages work? Could this be because PHP interacts with half a dozen other languages? Sure, you can use "placeholders" (bound parameters) with SQL, but can you use "placeholders" with HTML forms? No, you need to sanitize your output. Good thing PHP includes those functions. PHP was originally written to be super easy to use. As the featureset grew, they disabled some of the easier things. Register_globals is stupid today, which is why it's been deprecated for 10 years. There's a PHP.ini command to disable this, which is off by default. He even complained about a similar command above. Conclusion Or you had a morbid fascination with the awful arguments being presented and were unable to turn away, like a car crash.

As thorpe said, you haven't told us what "this" is. But I think it's safe to say that you're not doing it right if you're trying to make a flat file on your filesystem, you're not doing it right. That's how it's done, yes.

This disallows almost every page of a WP install. Specifically this line: Disallow: /*? Unless you have mod_rewrite enabled, this blocks everything. What do the URLs to your site look like?

Christian is right, but note that the "constant" SiteDescription probably needs to be quoted.

But...why? Why not make a PHP page that spits out a json-formatted document from the database every time you call it? Why all these extra steps?

What have you done so far? Are you honestly asking a group of strangers to spend a week writing something for you for free?

I figured he didn't actually mean "total comments in the table," but we may never know.

Only true for certain storage engines which store row_count in the table's metadata. IIRC, it works instantly on MyISAM, but slower on InnoDB. But the OP was asking for number of comments per topic anyway, I think.

Another thing I noticed: Typo? Or the actual problem? Either way, Christian is right. Cookies are wrong for this, use the session. Then you don't have to mess with setcookie() or anything, just treat the session like one big array: $_SESSION[$domain]['quota']; //etc.

SQL_CALC_FOUND_ROWS won't work on ultra-large result sets, like billions of rows. It's best to use some other sort of counting/estimation tactic separate from your query for that.

Why do you believe the cookie is full of data about your domains? That's probably the first question you should answer. Have you used setcookie() for some reason to fill this data to the user's cookies on their computer? Have you done print_r($_COOKIE) to see what's in the cookie?

You can also use SQL_CALC_FOUND_ROWS if you're paginating the results.

Psycho's code is correct. If that's not what your code looks like, show us the full block like that.

Are you looking for something other than "Move the HTML code outside the while loop"?

This topic has been moved to MySQL Help. http://forums.phpfreaks.com/index.php?topic=364092.0

Welcome to the forum. Please use [ PHP ] and [ /PHP ] tags (no spaces) to wrap your code so it's easier for us to read. The <?=$var?> syntax is deprecated and no longer works in PHP. Whatever you're learning from is at least 10 years out of date and should be thrown away. You need to replace that with <?php echo $var; ?> You should also know that this code will throw a warning under normal operation, and if you're developing without all your errors turned on you'll never learn properly. At the top of your script, put: error_reporting(E_ALL); Then, the correct code for inside your box is: <?php echo (isset($var) ? $var : ""); ?> Where $var is whichever variable you were trying to use the short syntax for.

Yeah, you're definitely including this file twice. If you're unsure of which files are being included or why, you should look through your code until you figure it out. And 'global' is definitely wrong.

@fenway, I was unioning the two tables in the inner select so that the counts were accurate @barand: That's exactly right, I completely forgot about union all. That's the issue. You can fix it either with UNION ALL or by including the timestamp in the inner query.

You're only selecting the ID from the inner tables. Perhaps you're not getting the right number. Try this: $get_totals = mysql_query("SELECT id, COUNT(timestamp) AS total_count FROM ((SELECT id, timestamp FROM TABLE1 where timestamp >= '$startTime' and timestamp <= '$endTime') UNION (SELECT id, timestamp FROM TABLE2 where timestamp >= '$startTime' and timestamp <= '$endTime')) as x GROUP BY id ORDER BY total_count DESC LIMIT 10"); If that doesn't work, do the inner query only (table X) and see if there are any duplicates. Maybe there just aren't.

SELECT id FROM ((SELECT id FROM TABLE1) UNION (SELECT id FROM TABLE2)) AS Foo

select id, COUNT(id) AS total_count from ((SELECT * FROM TABLE1 where timestamp >= '$startTime' and timestamp <= '$endTime') UNION (SELECT * FROM TABLE2 where timestamp >= '$startTime' and timestamp <= '$endTime')) GROUP BY id ORDER BY total_count DESC LIMIT 10

This topic has been moved to MySQL Help. http://forums.phpfreaks.com/index.php?topic=364235.0