What AI researchers seem to be doing is skipping the sensory input part, because it's hard
The sensory input part is easy. It's the subjective experience part that's hard. Well, calling it hard is misleading; it's impossible with purely computational approaches.
They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.
Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!
It's pretty obvious that Resig et al. don't have a clue. The "work arounds" are "fucked up" because they were written by rank amateurs who *still* don't know what they're doing!
As far consistency between browsers, I agree that things have improved. Even IE. So much so, in fact, that a few polyfills is often more than adequate to take care of the differences between browsers. (Just be careful with them. Some are great, while others are total garbage.)
Read the links I posted and dig around comp.lang.javascript for a little bit. If you're still advocating the use of jQuery after that, I don't know what to tell you!
My view on the matter is anyone who is criticizing Jquery / Dojo / and is suggesting vanilla javascript is completely ignoring the fact that the reason allot of these frameworks exists is the base implementations are horribly, horribly broken and the effects of a piece of javascript can be inconsistent even within the same browser.
But neither jQuery or Dojo actually solved the problem! (Sometimes they'd even make the problem worse...) The myth from years ago was that jQuery took care of all your cross-browser concerns. That was never even a little bit true. jQuery was, and still is, inconsistent across even the few browsers it claims to support. That's to say nothing of it's ever-shifting API!
Things are not nearly as broken as you seem to think they are. The differences between browsers can easily be managed by knowing what features to avoid -- and you don't need to avoid very much at all! Usually a small and simple polyfill or two will take care of any features you need -- even if you need to support antique versions of IE.
Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)
I don't know, dynamically change the element's CSS depending on the resolution and orientation?
If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.
As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)
And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.
Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.
I don't think there is a competent programmer alive who does not use libraries.
Read my post again. I'm not arguing against all libraries, just their unnecessary use. In the case of jQuery, jQuery Mobile, and jQuery UI their use is not only unnecessary it's actually harmful -- particularly on mobile.
What if you're developing a website that needs to be responsive for all orientations, both desktop and mobile?
If you're using JavaScript for layout, you've already failed.
Sadly, the best you can do is get them to drop down. At least it takes very little JavaScript to make your CSS menus work on touch screens, and less code is always a good thing.
You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow.
No, I've been claiming that jQuery is slow and crappy all on it's own. jQuery UI and Mobile just happen to be even slower.
jQuery is not a performance killer.
Actual data suggests otherwise. This is completely objective. You can test this for yourself. You pay a VERY steep price for using jQuery even for very simple things.
What it does do, however, is cut development time considerably.
Have any metrics? From what I've seen, it adds significant development time over the life of the application. Do you know how common it is to see multiple versions of jQuery loaded on the same page? (jQuery even has features to help allow that to happen!) Do you have any idea how difficult is is to dig someone out of a mess like that?
The only way jQuery could possibly "cut development time" is if you never maintain your code -- and only then if typing speed is your biggest bottleneck.
I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.
Have you looked at the jQuery codebase? It's like a group of amateurs that didn't understand either JS or the DOM wrote a library. Oh, wait, that's exactly what happened! (Seriously, check the Usenet archives. It's a riot.)
No surprise, the developers are still less than competent. How on earth did this abomination get so popular? It's a complete mystery to me.
Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.
Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions.
Nonsense. jQuery has *never* been cross-browser -- and never really did well across the few browsers it claimed to support! The word "consistent" is a bad joke. when paired with "jQuery". How long has it been around now? It still doesn't have a stable API!
Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.
If it was you wouldn't see it on nearly every website more complicated than "hi my name is
See my earlier post. Take the challenge and see how various websites actually use jQuery. If you're not completely disgusted, I can't help you.
Here's why see jQuery used everywhere: JavaScript is difficult to learn. Well, that's not quite right. It's really easy, actually, but it's not at all like Java, C#, or any other popular language. It just looks a lot like popular languages. That causes a lot of confusion from developers who are used to picking a new language by reading a few code samples and hitting google a few times. You simply can't learn JavaScript that way.
jQuery came with false promises like cross-browser compatibility and a myth of ease-of-use. Developers who never touched JavaScript before took jQuery as an "easy way out" -- never mind that none of the promises it made were ever true, that's what they were told and that's what they believed. They were told that JavaScript is difficult or full of pitfalls. That wasn't true, of course, it's just that the language was so different from what developers were used to from language's with similar syntax that they m
It's pretty well-known that jQuery is an absolute mess. A lot of effort has gone in to improving it, sure, but that sort of makes the point, doesn't it? Take a look through the code yourself. It still isn't pretty.
To call it "memory-lite" is just absurd. (Get a profiler and run some tests if you have trouble believing that.)
jQuery isn't stellar, obviously, but it makes jQuery UI and jQuery Mobile look positively light-weight in comparison! jQuery has often been blamed for PhoneGap's performance problems. Again, this is something you can see for yourself.
Even the most ardent jQuery fan will acknowledge that jQuery (expecially jQuery UI and Mobile) is a performance killer, they'll just say "it doesn't matter because computers are getting faster every year" or something equally silly in defense of their favorite library. To claim that jQuery is actually *faster* than a native solution is just crazy.
Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?
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.
Yeah, we know about document.querySelector()
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!
Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.
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!
So does using the "but everyone else is doing it" argument.
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.
Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it.
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.
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 fewneatdiscussions that may be helpful for you.
, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem
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.
the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.
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.
you don't understand why unnecessarily verbose code leads to more bugs
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.
No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated
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.
The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly
Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!
Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result
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.
I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages
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.
An example of a design flaw is PHP's === equality operator not working consistently and it's == operator not being transitive. There's not excuse for this
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.)
One language is better than another if it has less design flaws
That's not an answer to the question. What are these "design flaws"? How can they be identified?
The required additional syntax to create a new scope to make this work is nonsensical and a result of the lack of foresight in the language's design
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!)
Surely you must at very least understand that simplified and more readable syntax to solve an identical problem is both better for developer efficiency and is better for supporting less buggy software.
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.
I hope you can finally grasp why unnecessarily verbose code to solve simple problems resulting from lack of foresight during language
Slashdot Mirror
What AI researchers seem to be doing is skipping the sensory input part, because it's hard
The sensory input part is easy. It's the subjective experience part that's hard. Well, calling it hard is misleading; it's impossible with purely computational approaches.
You say that like we have anything remotely like the kind of AI implied by the summary.
We're not even close. Hell, we don't even understand the problem at the simplest level. (Hint: The GP's 6-month-old comment was spot on.)
They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.
Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!
"fuckin' coons" ... "they always get away"
Nothing racist in there at all, yeah?
Perhaps Zimmerman shouldn't pick fights with people if he doesn't like the consequences?
Lucky for him, he now only needs to decide if he likes shooting black kids more than he dislikes taking a few knocks...
This won't end well.
querySelector and querySelectorAll are both fully supported by IE8.
addEventListener support can be added with a very small polyfill.
See my other posts for some links. If you're still advocating jQuery after that, no one can help you.
Then can the browser vendors at least look at the fucked up work arounds they had to do to get jquery to even work and fix them?
The problem is that jQuery is so poorly implemented -- and so badly broken that there no value can be gained from its examination!
It's pretty obvious that Resig et al. don't have a clue. The "work arounds" are "fucked up" because they were written by rank amateurs who *still* don't know what they're doing!
As far consistency between browsers, I agree that things have improved. Even IE. So much so, in fact, that a few polyfills is often more than adequate to take care of the differences between browsers. (Just be careful with them. Some are great, while others are total garbage.)
Read the links I posted and dig around comp.lang.javascript for a little bit. If you're still advocating the use of jQuery after that, I don't know what to tell you!
My view on the matter is anyone who is criticizing Jquery / Dojo / and is suggesting vanilla javascript is completely ignoring the fact that the reason allot of these frameworks exists is the base implementations are horribly, horribly broken and the effects of a piece of javascript can be inconsistent even within the same browser.
But neither jQuery or Dojo actually solved the problem! (Sometimes they'd even make the problem worse...) The myth from years ago was that jQuery took care of all your cross-browser concerns. That was never even a little bit true. jQuery was, and still is, inconsistent across even the few browsers it claims to support. That's to say nothing of it's ever-shifting API!
Things are not nearly as broken as you seem to think they are. The differences between browsers can easily be managed by knowing what features to avoid -- and you don't need to avoid very much at all! Usually a small and simple polyfill or two will take care of any features you need -- even if you need to support antique versions of IE.
Yes, that's correct. Now ask yourself why JavaScript need enter in to it at all? (Are you going to advocate browser detection? You'll find more than enough on comp.lang.javascript about that bad practice!)
I don't know, dynamically change the element's CSS depending on the resolution and orientation?
If that becomes a need, chances are you've already failed. When it makes sense, which is rare, you'll find mobile browsers more than capable thanks to long-standing and broad CSS3 support across the major platforms.
As for the handheld media type, your article is woefully out-of-date. CSS3 Media Queries are far from "non-standard" in case you didn't know. (I should also point out that for mobile devices, in virtually all cases, it's not necessary to change your CSS at all. If you found some bizarre case where that was necessary, using the outdated handheld media type wouldn't make sense anyway!)
And you want to use a heavy-weight JavaScript library to "fill in the gaps" (that likely don't exist) on a subset of antique devices where you might find a minor layout problem? That's insane. I'll take it a step farther and guarantee that you'll find more "gaps" using JavaScript for layout on old mobile devices than you will with CSS.
Anyhow, I'm not going to argue with you about this. It's clearly going to be a huge a waste of my time. Unless your incompetent, you'll figure this out on your own eventually.
Good luck.
Do you actually need to ask? I don't even know where to begin! Do a google search, you'll find much more that I could possibly jam in to a forum post.
(Other users who are not completely floored by the question: feel free to chime in.)
Learn to use CSS. In the context of this discussion, pay particular attention to @media
I wonder if you use tables for layout as well...
I don't think there is a competent programmer alive who does not use libraries.
Read my post again. I'm not arguing against all libraries, just their unnecessary use. In the case of jQuery, jQuery Mobile, and jQuery UI their use is not only unnecessary it's actually harmful -- particularly on mobile.
What if you're developing a website that needs to be responsive for all orientations, both desktop and mobile?
If you're using JavaScript for layout, you've already failed.
Ignoring the fact that it's broken and incompetently written, it also has a very unstable API.
Add to that the ridiculous feature overlap between jQuery and vanilla JS and it's clear that such a fit would be very uncomfortable.
Sadly, the best you can do is get them to drop down. At least it takes very little JavaScript to make your CSS menus work on touch screens, and less code is always a good thing.
You keep claiming jQuery is slow and crappy because a few frameworks that exist on top of it are slow.
No, I've been claiming that jQuery is slow and crappy all on it's own. jQuery UI and Mobile just happen to be even slower.
jQuery is not a performance killer.
Actual data suggests otherwise. This is completely objective. You can test this for yourself. You pay a VERY steep price for using jQuery even for very simple things.
What it does do, however, is cut development time considerably.
Have any metrics? From what I've seen, it adds significant development time over the life of the application. Do you know how common it is to see multiple versions of jQuery loaded on the same page? (jQuery even has features to help allow that to happen!) Do you have any idea how difficult is is to dig someone out of a mess like that?
The only way jQuery could possibly "cut development time" is if you never maintain your code -- and only then if typing speed is your biggest bottleneck.
I won't claim that jQuery is faster than every native solution. But it is probably faster than your native solution. And infinitely more maintainable.
Have you looked at the jQuery codebase? It's like a group of amateurs that didn't understand either JS or the DOM wrote a library. Oh, wait, that's exactly what happened! (Seriously, check the Usenet archives. It's a riot.)
No surprise, the developers are still less than competent. How on earth did this abomination get so popular? It's a complete mystery to me.
Or do you mean code written using jQuery? Now that's impossible to maintain! (For reasons mentioned earlier and later.) Add to it that jQuery code is mostly written by amateurs who don't know any better (or professionals that don't want to face the simple fact that JavaScript is not C# and they'll need to learn some new concepts). When you see jQuery, you can safely assume that the code is a mess anyway.
Provides a consistent experience across most browsers and gracefully falls back when browsers don't provide native solutions.
Nonsense. jQuery has *never* been cross-browser -- and never really did well across the few browsers it claimed to support! The word "consistent" is a bad joke. when paired with "jQuery". How long has it been around now? It still doesn't have a stable API!
Oh, and did you hear? They're dropping support for IE8 and below. Not that it did a great job of supporting those browsers anyway, but it's yet another reason that jQuery has LONG outlived its utility.
If it was you wouldn't see it on nearly every website more complicated than "hi my name is
See my earlier post. Take the challenge and see how various websites actually use jQuery. If you're not completely disgusted, I can't help you.
Here's why see jQuery used everywhere: JavaScript is difficult to learn. Well, that's not quite right. It's really easy, actually, but it's not at all like Java, C#, or any other popular language. It just looks a lot like popular languages. That causes a lot of confusion from developers who are used to picking a new language by reading a few code samples and hitting google a few times. You simply can't learn JavaScript that way.
jQuery came with false promises like cross-browser compatibility and a myth of ease-of-use. Developers who never touched JavaScript before took jQuery as an "easy way out" -- never mind that none of the promises it made were ever true, that's what they were told and that's what they believed. They were told that JavaScript is difficult or full of pitfalls. That wasn't true, of course, it's just that the language was so different from what developers were used to from language's with similar syntax that they m
It's pretty well-known that jQuery is an absolute mess. A lot of effort has gone in to improving it, sure, but that sort of makes the point, doesn't it? Take a look through the code yourself. It still isn't pretty.
To call it "memory-lite" is just absurd. (Get a profiler and run some tests if you have trouble believing that.)
It's also hard to argue that a complex generalized solution to some problem will be faster than one written with a specific case or set of cases in mind. The abysmal performance of jQuery for even simple operations is evidence enough of that. (See any one of a zillion tests, or run a few of your own if you can't find one to your liking and you'll see what I mean.)
jQuery isn't stellar, obviously, but it makes jQuery UI and jQuery Mobile look positively light-weight in comparison! jQuery has often been blamed for PhoneGap's performance problems. Again, this is something you can see for yourself.
Even the most ardent jQuery fan will acknowledge that jQuery (expecially jQuery UI and Mobile) is a performance killer, they'll just say "it doesn't matter because computers are getting faster every year" or something equally silly in defense of their favorite library. To claim that jQuery is actually *faster* than a native solution is just crazy.
Just for fun
Sure, I could write native applications for every device listed under the supported devices section, but why is it smart to do that when I can write a single codebase that I can package for multiple devices?
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.
Yeah, we know about document.querySelector()
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!
Learning a flaky, inconsistent language
JavaScript is "flaky" and "inconsistent"?
What on earth are you talking about?
Since JavaScript is so damn lacking, those libraries are ESSENTIAL for anything beyond the smallest JavaScript app.
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.
So does using the "but everyone else is doing it" argument.
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.
Really the biggest problem with PHP is not the language itself, however, it's all the bad information out there about how to use it.
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.
You claim OOP isn't defined when it is
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.
, you claim it's just how closures work and C# works the same whilst demonstrating how Microsoft have fixed the very problem because it is a language problem
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.
the fact you're entirely unaware of the problems in it's equality operators shows how painfully little knowledge you have.
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.
you don't understand why unnecessarily verbose code leads to more bugs
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.
No it isn't indisputable fact, and where it's "established" in literature that literate is rather old and dated
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.
The arguments made a bit more sense when keywords like protected weren't implemented, or were implemented poorly
Again, you don't understand the problem. It's a fundamental problem, not something that can be fixed by adding a few language features!
Compare and contrast this to the original argument that Javascript does not properly implement OO and is badly designed as a result
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.
I've explained twice why inheritance doesn't inherently have to break encapsulation in well designed languages
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.
An example of a design flaw is PHP's === equality operator not working consistently and it's == operator not being transitive. There's not excuse for this
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.)
One language is better than another if it has less design flaws
That's not an answer to the question. What are these "design flaws"? How can they be identified?
The required additional syntax to create a new scope to make this work is nonsensical and a result of the lack of foresight in the language's design
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!)
Surely you must at very least understand that simplified and more readable syntax to solve an identical problem is both better for developer efficiency and is better for supporting less buggy software.
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.
I hope you can finally grasp why unnecessarily verbose code to solve simple problems resulting from lack of foresight during language
That's a relief. I was worried about lamp-wielding caddies terrorizing the back nine.