Here's what you don't realize: You don't need a giant library or framework to do that. If you know what you're doing (and it doesn't take much knowledge or skill) you can deploy your mobile app across various platforms and devices from a single codebase -- without any platform or device specific code save what's necessary for packaging. You can effortlessly deploy from the same code base to BlackBerry, Android, and iOS -- no framework needed.

Now, if you want to use something like PhoneGap to make it easier to use features like accelerometers, gps, etc., that's much more reasonable. There's an actual benefit to libraries that offer specific functionality (three.js, for example). You'll find, however, that things like jQuery mobile *will* kill your performance.

I clicked on the first link and scrolled a down a bit.

The answer appears to be "most of them" and "most of the remainder if you know how to write for loop".

Like I said earlier: do the web a favor and just learn JavaScript.

You'll find that it's not only easier, but your code will be significantly faster. If you're dropping jQuery, you'll find that your code is also significantly easier to read and maintain. No need to make giant chains just to get your performance from "horrible" to "terrible" -- you get "acceptable" automatically, and "good" or "fantastic" once you have a better understanding of the language.

Apparently not. Take a look around the web. You'll find that the bulk of jQuery use can be replaced by querySelector and querySelectorAll -- often just by getElementById and getElementsByClassName.

Really, I've seen lot's of sites and code samples that use jQuery just to select a single element by id! All because the author either didn't know about getElementById or was too lazy to type it out. It's horrifying.

There are other stupid uses as well. Dropdown menus built with jQuery, like the popular superFish menu. What makes this particularly crazy is that it's trivial to build a dropdown menu without jQuery, or any JavaScript code at all! All you need is a little CSS. (Just a few lines, as it turns out.) If you don't have the 10 minutes it takes to figure it out yourself the first time, there are several websites that will generate a cross-browser pure CSS dropdown menu for you with just a few simple clicks!

JavaScript is "flaky" and "inconsistent"?

What on earth are you talking about?

That's because you're not familiar with JavaScript. Remember: all those "essential" libraries are written in JavaScript. You'll find that tons of features in those bloated libraries are just useless wrappers!

It's not 2006 any more. If you're still using jQuery, or some other goofy library, you're just wasting everyone's time.

You'll find that just about every feature your "essential" library provides has a native equivalent that works across browsers -- even as far back as IE 8.

Do the web a favor and just learn JavaScript. You'll find that it's more than capable. Your users will undoubtedly appreciate the performance boost!

Not quite what I meant -- see my other reply. Apparently I can't communicate ideas today.

That's not the argument I'm making :)

PHP is ubiquitous. That's certainly an advantage as far as maintaining it's share of the web. However, that didn't happen overnight. PHP is ubiquitous today because it did the job it was designed to do better than competing languages. This is still true today, as evidenced by several "superior" fad-languages failing to gain any ground. If PHP was garbage that no professional would touch, it couldn't have possibility achieved such an astonishing share!

You can criticize any language you want. With enough effort, you can make C appear to be the worst language ever improperly designed. (Just poke around the usenet archives and you'll see what I mean.) PHP has it's share of warts, no question, but it's not the worthless pile of garbage that language snobs have made it out to be.

You'll find that's true of all popular programming languages. (You should see the nonsense out there about JavaScript -- written by respected professionals!) Though I'll admit that it might be a bit worse for PHP due to the large number of beginners the language attracts due to it's astonishing ease-of-use.

Really, I think that ease-of-use is exactly why we see so many "PHP is garbage" comments on forms like this. Developers are (undeservedly) considered by the general public to be brilliant-- a bit like MD's. The difference, of course, is that anyone can become a computer programmer in their spare time -- even children. Hell, I'll bet that the majority of Slashdot users were writing games for their home micro before the age of 12. It's an easy skill to learn -- and everyone developer knows it. Being insecure, the last thing they want is some easy language out there that's easy to learn and use. If their little secret got out, no one would think they were brilliant! They'd just be another nobody -- their worst fear!

Languages like PHP are a huge threat to those insecure developers. I'm not surprised that they bash it at every opportunity.

Yeah, only idiots use PHP -- that's why it's only used by 80% of the web.

Language snobbery benefits no one. Unless you're Chuck Moore, it also makes you look like an idiot who can't form their own opinions.

Indeed. GOTO is not inherently evil. You'll find it used appropriately in some surprising places -- including the Linux Kernel.

When describing a process, the oft-maligned GOTO certainly comes in handy. The over 30 crowd might remember seeing GOTO's in any number of guide books from auto repair to taxes. (The word wasn't always used, sometimes "skip to ..." or "continue with ..." etc.)

That's right: GOTO can actually make things easier to read and understand.

Even in software today, I'm willing to bet even the most ardent anti-GOT zealot has used a GOTO -- and recently at that -- cleverly disguised as a break or return statement.

No, I said that there was no consensus on the definition. That is true. Indeed, it's indisputable! You seem to like wikipedia, so you can check there. I did a quick google seach for you and found a few neat discussions that may be helpful for you.

Pay attention. Microsoft changed how foreach works, not how for works. Your example deals with for loops. You'll find that my statement is correct.

Additionally, you should consider what a similar "fix" for the non-problem in for loops would entail, and why the behavior of for remains the same.

That's all irrelevant, however, as the problem the poster had in the example you gave was a simple misunderstanding of how closures work. It's not a language design issue.

Pray tell, then. What are the problems? (I've explained why NaN!=NaN already. See IEEE 754 if you forgot) If you're talking about things like intransitive equality, you're just confused. You'll find identical behavior in virtually every other language. Not just those with dynamic typing -- recreate the examples you found in some blog post in Java or C, applying relevant type casts. Look at that! The behavior is the same!

Now, you're welcome to list which type conversions you find irrational, though once you look, you'll find they're all perfectly sane. It behaves exactly as you would expect from experience with your exemplar languages.

Check my post again. I agreed with that specifically. I also challenged you on Java (one of your exemplars) as it is unnecessarily verbose! JavaScript and PHP are positively terse in comparison.

I will offer, for your consideration, that unnecessarily terse code also is less readable, often leading to more bugs and making maintenance difficult.

Moving on. I find it odd that in response to evidence that directly contradicts your claims, and which support my own, you offer only bold assertion.

I asked you some very simple questions so that you could make a stronger case. (Well, to let you actually make a case!) If I'm wrong about something, I like to know. I'm disappointed that you'd rather insult me than actually discuss the issues.

This whole dialog started with your objection to some simple advice I offered another user: don't use JavaScript like it's a class-based OO language. I still don't know why you found that unreasonable, as JavaScript is prototype-based. (There's a paper you might find instructive here: D. Ungar & R. B. Smith (1987) "Self: The Power of Simplicity", OOPSLA '87 Conference Proceedings, pp. 227-241)

Anyhow, with this post I've left you with some reading and experimenting to do. Give it a go and let me know the results. I expect that you'll be unpleasantly surprised.

So we should toss out relativity and quantum mechanics as well, eh? (Old doesn't mean invalid.) Put that ACM DL subscription to good use. You shouldn't have too much trouble finding more modern if that's important to you.

Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!

A couple things: 1) There is no such thing as "proper" OOP. There is no consensus on the definition. 2) You have not established that JavaScript "does not properly implement OO" As I explained earlier, it's prototype based, not class based -- like several other languages. It's not bad simply because you don't like it.

The problem is that your explanations don't actually address the issue at all! Again, it's fundamental -- this is very well established in the literature. It's not magically changed simply because a book you found on wikipedia and the paper I offered were older. Put that ACM DL subscription to use and find something to make your case -- you'll find that it's indisputable: Inheritance breaks encapsulation.

Assuming you're talking about the NaN thing from before, you'll find that it's a natural consequence of IEEE 754 -- and that that behavior is correct and expected in all languages. (Seriously, it's in the damn standard.) If you're speeking more generally, you'll find that PHP's == and === operators do indeed work consistently, behaving like similar dynamically typed languages. (Go ahead and try out some of the examples you found of "inconsistency" online in C, with explicit casts and you'll find the behavior is identical. Don't like C? The same will hold for Java as well.)

That's not an answer to the question. What are these "design flaws"? How can they be identified?

No, the problem was that the stackoverflow posted doesn't understand closures. You'll find the EXACT same behavior in C# -- one of your exemplar languages. In fact, this confusion over closures lead Microsoft to change the behavior of foreach loops!

It's not an issue of language design, it's just how closures work. (Imagine how bizarre and unexpected the behavior of for loops would be if MS decided to change their behavior to match that of foreach!)

Readability is important. I couldn't agree more. However, in the example you gave, C# behaves just like JavaScript. It's not a language design problem. It's not a problem at all. It's just how closures work.

Now we've got to the meat. Is this what constitutes bad design in your eyes? Simply unnecessarily verbose code to solve simple problems? Should we all switch to Forth? Java is particularly verbose -- is it badly designed? You held it up earlier as an exemplar.

That's a relief. I was worried about lamp-wielding caddies terrorizing the back nine.

So... It's a bad idea to play golf?

No, it's true. Inheritance breaks encapsulation. This is a indisputable fact. It's VERY well established in the literature. The problem, it seems, is that you simply don't understand what that means. Do you have an ACM DL subscription? If not, get one. You'll find plenty has been written about that very subject.

Have any evidence? Because I don't think you do. (I think you're making this up as you go along.) Where's the research? Make use of your ACM DL subscription.

That's not fair. I know you can't actually produce anything like that. How about some specific examples like I asked for in an earlier post? Surely, you have something specific in mind?

Now, I will agree that people don't use JavaScript correctly. That was the point of my first post. The problem isn't the language, of course, but people trying to use the language like it's a class-based, not prototype-based. Once you learn the language, you'll find that there's nothing wrong with it. There are no "quirks", as you like to say, it's just different. Give Scheme and Forth a go and you'll find they're just as different, but not poorly designed in any way. (The difference? You can't pretend that Scheme and Forth are just like Java and C# like you can with JavaScript. If there's any problem with JavaScript, it's that the familiar syntax makes naive developers think that there's nothing new to learn.)

Again, what makes a language poorly designed? What makes a language "better designed"? Is there some ultimate ideal language design? I still don't think you've thought this through.

I did no such thing! (I actually had a much older paper in mind when I told you that inheritance breaks encapsulation.) You had never heard of such a thing and did a google search (as I asked), landing on Wikipedia, where you learned that the subject was mentioned in the GoF book.

I'm not willing to learn?!

How about answering the very basic questions about your assertions? Asking questions shows a willingness to learn, doesn't it? I've not asked any difficult questions, after all. If you want me to learn, surely you could take the time to answer them, or at least direct me to the relevant research from which I'm sure you've formed your opinions?

You're not just repeating empty platitudes, right?

Umm... Inheritance is fundamentally incompatible with encapsulation. This isn't exactly a big secret. Google "inheritance breaks encapsulation".

Well, what are they? (Dare I ask after your failure to do the same for JavaScript?) One of the greatest strengths of PHP is that it is incredibly simple to learn and use. What are these mysterious quirks that millions of amateurs are apparently willing to slog through learning before hacking out yet another home-grown CMS?

What are these so-called "poor design traits that result in inherently more buggy software". More buggy that what?

I don't think you've thought this through.