To use your analogy, we're letting people with normal sight use handicap assistance dogs in the shop. They just think they need the dog, they don't. But we can't legislate a cure for delusion. The best we can do is make the test for who needs handicap assistance more strict so that only genuinely disabled people can use them.
Otherwise, every idiot that wants to bring a traveling zoo into the store has a carte blanche excuse to do it, and until someone invents reliable mind-reading equipment we have no justification for preventing it.
So if a psychiatric patient believes that God wants him to walk around waving his genitals at people, we have to allow it because of his religion?
If the answer is yes, then I'm going to announce that my soul is imperiled unless the United States government pays me a million dollars per day. It's the Church of Just Fucking Make Me Rich, and Jesus, Allah, and Joseph Smith came to me in a vision and said I had to found it or I would be damned.
Robert Heinlein had some wacky ideas, but in one of his books he has the guideline, "Thou shalt pay lip service to the prevailing religious belief of thy culture." i.e. When in Rome, act like the Romans do.
The crazy religious people are still an overwhelming majority in the US, I suspect we're at least one or two generations away from the time an atheist could be elected president. I wouldn't be surprised if most of the Presidents and Presidential candidates of the last fifty years were closet atheists who pretended to Christianity for the sake of winning the election.
If I argue that ROT13 is the ultimate unbreakable encryption scheme on Slashdot, or that Windows 95 is the most secure operating system ever created, I would get ridiculed and I would deserve to get ridiculed. Religion is no different.
The site is often friendly to people asking questions, but it's harsh to people asserting illogical ideas.
What? Have you listened to the religious folk? You'll find millions of reasonable, pleasant, even brilliant people if you engage in polite conversation about other topics. Bring up faith and they string together a series of logical fallacies that make your head spin and a supreme being that's some bizarre unknowable sadist but somehow represents all that is good in the universe. I defy you to find an exception, except maybe Buddhism - but depending upon the sect, some Buddhism is more personal philosophy than religion.
Note also that almost all war and murder before the 20th century had religious belief as a motivator for the conflict or was a secular conflict conducted by devoutly religious people. The Civil War was secular, but faithful Christians were butchering each other over a practice almost no atheist defends as moral - slavery.
It might be a better idea to arm women everywhere, and maybe put more effort into teaching men that rape is wrong and also teaching everyone to intervene when they suspect a rape is in progress. The saddest part about the rapes and gang rapes in the news these past few months in the US is the actual rapes - but the second saddest part is that other people present at the social events suspected what was happening and neither intervened nor alerted the police.
These days "agnostic" is typically interpreted as, "I don't know if god exists." The original meaning of the word is closer to: "I don't think it's possible for humans to understand in any meaningful way whether god exists." I call myself an atheist because it's simpler, but really I think (not believe) the older meaning of the word agnostic is correct.
But Charliemopps is belittling a serious problem - many Christians, Muslims, Mormons, and members of other religions are trying to inject their religious beliefs into civil law. You want to live your own life based on selective interpretation of the Bible? Fine. You want me to follow the same rules? No. That is why atheists and agnostics need to have a public presence in our modern time - to keep the people who think the creator of the universe is intensely concerned with whether they eat shellfish or what days of the week they pray from writing the laws.
For home computer users, it's far easier for someone wanting to listen to your internal network traffic to crack WEP than physically tap into your cat5 cables somewhere in the house. Listening in wirelessly takes a laptop in a car outside the home, listening to the wired network requires at a minimum a physical home invasion - obviously the person can tap your phone, coaxial cable, or fiber connection between the provider and your house, but that doesn't give them the same internal network access as physically tapping your network inside the home router.
And you can't really expect every home user, or even most home users, to go through the trouble of setting up an in-home VPN in addition to their wireless network. You have to assume that for home users, WEP was originally intended to be their complete security solution - and it was a total failure.
TKIP modifies WEP to be secure, and TKIP runs on any hardware that can run WEP.
WEP was designed to be secure, nobody would go through the trouble to invent a security protocol that they knew could be defeated by commodity hardware in under an hour. WEP was just designed poorly.
Even for companies that primarily write software, it's easy to design something that looks secure to you but in fact is trivial to defeat. WEP wireless security is inherently flawed. PPTP VPNs from Microsoft are inherently flawed, though not as badly as WEP, and Microsoft has deprecated the entire protocol. WPS wireless easy setup is flawed. The AES encryption used by Megaupload in their re-launch earlier this year was not implemented properly, and thus is useless.
The history of computing is littered with flawed attempts at designing new security protocols. As far as I can tell, the best practice is to adopt an existing open source technology that is well proven. If you're trying to do something new, you probably need to spend an unholy fortune on multiple independent audits of the system, as well as inviting people on security mailing lists to examine it, and possibly offering a bounty for discovered flaws.
Right. But nobody in the Lisp community has the authority to fix the situation - and as you noted, the community is full of people who are opposed to any such fix, so the chances of someone entering the community to fix it is small.
So the best possible solution, weak though it may be, is to create something new that just borrows strengths from Lisp but is intentionally different. Clojure is that kind of attempt at a fresh start, and it breaks some Lisp syntax (using square brackets in some cases) and intentionally does not have compatibility with the Common Lisp standard. Maybe that's more balkanization, but maybe these intentionally more different offshoots have a chance to succeed when the dialects that are closer to each other have failed.
If you read articles on Lisp dialects on Github, the sad news is that Emacs Lisp configuration files are the most popular Lisp variant. That's great for fans of Emacs, not so great for people who want to see Lisp widely adopted. Outside of those files, the two most popular Lisp dialects are Clojure and Racket - which I believe are the two versions of Lisp that are furthest from the Lisp core family.
Armed Bear Common Lisp is a full Lisp implementation on the JVM. To my knowledge its popularity is miniscule. Clojure is newer, not a standard Lisp, and it's used hundreds of times as often.
I'm a Clojure fan, sorry.:) Clojure offers many things, but I think the three most important features it adds to the standard Lisp strengths are: 1. Variables are immutable by default, though there are mechanisms for traditional mutable variables you have one extra step to use them. That makes it easier to reason about your code, without forcing every variable to be immutable like Haskell. 2. It's interoperable with Java, so aside from the relatively small Clojure standard library your extended "standard library" is the Java standard library. Plus of course you can use any of the tens of thousands of other existing Java libraries. That of course also provides Clojure with a single solution to the standard libraries question - under the hood you use java.net for networking, java.io and java.nio for IO, etc... 3. It's interoperable with Java, so the learning curve for developers and the adoption curve for tens of thousands of existing companies is much more straightforward than bringing in another Lisp dialect that's only compatible with C++, C#, Perl, Ruby, Java, etc... by using foreign function interfaces.
I think your point about multiple conflicting implementations and disputes between them is insightful. I do think that's the reason Clojure may have a better chance at mainstream adoption than any other Lisp dialect of the past 20 years.
Maybe I was lucky, the first time I tried Clojure was within the past year and the installation worked flawlessly. My biggest problem with the language is that some error messages from simple mistakes (mis-aligned parenthesis, etc..) are obtuse - I consider that an obstacle to adoption of the language. I've acquired the patience to work past errors like that, even though they drive me bonkers for the first few weeks I'm learning a new language. But that kind of thing can and will make the difference between widespread adoption and fading to obscurity in the long term.
Once you do get comfortable with Clojure, the documentation search features right in the REPL are wonderful, so if you don't remember how to do a certain thing you can often find it quickly.
With regard to libraries, Clojure of course benefits from the fact that Java's standard library is rock solid. It's full of warts and odd inconsistencies, but it's reliable.
It's interesting that you mention D. It's one of the languages I spent some time learning when I began my "anything but Java" search, and I think the language itself is brilliant - definitely a huge evolutionary step forward from C++, in my humble opinion ahead of Google's Go language. But I hadn't realized the standard library was so weak, my exploration hadn't reached that far. That's a damn shame. Andrei Alexandrescu's "The D Programming Language" book is probably the best programming language book I've ever read.
Then you and I are using different criteria to measure practicality - though I suspect my criteria line up more closely with Guido's criteria than yours.
No matter how effective a tool is, if it's not in mainstream use that's a significant mark against its practicality. Four decent Lisp developers might be able to build a particular piece of business software faster and with fewer errors than fifteen decent Python developers - but if I can't find four decent Lisp developers in the local market, I'm still going to pick Python when I start the project.
If Lisp was going to take over the world, or even just be used in as much as 10% of the software created in any given year, it would have done it already. That, I think, is the entire reason why Clojure ( and before Clojure, Scheme and Racket, https://en.wikipedia.org/wiki/Racket_(programming_language), and since Clojure, Hy http://docs.hylang.org/en/latest/ ) have been created - attempts to tweak the Lisp formula into something more palatable for the mainstream without losing any of the core features that make the language useful.
I wish Lisp and Clojure were more prevalent. Most of my work experience is with Java, and now that I've become comfortable with Lisp and Clojure in my spare time I'm chafing at the tools I have to use for work. There just aren't that many jobs around, at least outside Silicon Valley, that use either language. So I'm trying to do useful Clojure stuff in my spare time in order to have a portfolio I can show off for a Clojure shop.
But to your point, I think Guido is safe to dismiss Lisp - it's a spectacular functional language, it's one of the most well known functional languages, and at least in original and Common Lisp form it just can't get traction in the mainstream.
Good points. Thanks again for injecting a reality check across the discussion.
But in the case of GUI testing, there are so many display resolutions and graphics processors and so forth in the Android world - which is the biggest target, of course - that your GUI testing is going to be extensive regardless of native vs. web if you target Android. iOS used to have a smaller number of targets, but now it's getting bigger (if not as big as Android).
While mobile site performance is often pitiful, mobile devices are getting more powerful and web browsers are getting more efficient. Native will always trump web for performance, but for an awful lot of simple applications the difference doesn't matter and every year the subset of apps where it doesn't matter is increasing.
If the technology takes off on other platforms, Apple will follow sooner or later. They have a big portion of the market and the most profitable portion of the market, but they can't ignore a technology that the other 60% use, no matter what it is.
Often the fix you're deploying is a security fix, so the native app user rejecting the update may be avoiding an annoying UI change, but they may be opening themselves to a hack. That's still a problem and not a clear win for native.
Net's down problem is legitimate. Forgetting to renew your domain registration is effectively the same as "net's down".
With a native app, there's a much better than even chance that Apple, Google, Microsoft, or AT&T, Sprint, T-Mobile, and Verizon can pull all your data off the phone anyway. Winner: none.
Setting up your own purchase system is a hassle, but the percentage taken by Google Wallet or Amazon Checkout or whatever is far less than what you pay in the typical App Store, where they get a 30% (typically) of all transactions and in some cases forbid you from advertising a lower price outside their app store.
If you are hacked, all of the people using your application between when you are hacked and when you take down the site until it's fixed are hacked. That's not all of your users, automatically. But yes, good point.
If your web server goes down, you're in trouble. But so many applications depend upon a web service anyway, so you get the worst of both - a native app that still doesn't work correctly if the backend is not available.
With the single code base across all applications, I mean it in the sense that it's all HTLM5 plus Javascript. Obviously you're going to have custom logic in the client or server based on the specific browser and platform the client is using - or you're going to use one of the third party libraries (modernizr, etc...) to handle the differences for you.
I'll grant you games, I don't ever see them being less than two or three generations behind in web vs. native. But in terms of camera, Firefox is making their own HTML5 APIs for manipulating the camera in Firefox OS and I believe they're trying to make it a w3c standard. If that technology becomes mainstream, there you go.
In most cases the performance difference is from 3-10x in speed or memory. But even at 20/20, that's better than Python, Perl, Ruby, and PHP, and those languages are used all over the place. Java has great performance when run for a long time because of the optimizations the HotSpot JVM applies to long-running processes, for those it can often match C++ performance speed. But Java even under the best circumstances uses 5-50 times as much memory as C++ for similar applications.
Flash is used all over the web and in many downloadable games, and I believe its performance is somewhere in line with Javascript, or worse.
That won't bring a home computer or laptop to its knees for many applications. I wouldn't use Javascript for Call of Duty 5, or a Video Editing program, but for a chat client or a music player, what difference does it make?
I wasn't responding to the original article, I was responding to SuperKendall.
But - maybe this makes me boring - the most common feature I use on my Android phone is bookmarks. I have my movie theater ticket purchase site bookmarked, the local weather site bookmarked, and a few others. I don't use many native apps. So the "performance and usability" advantage of native apps is meaningless to me, the only native app I installed is Firefox browser.
Because so much of the world relies on Javascript, the browser vendors are in a performance war and keep upping their investment in Javascript just-in-time compilation. Have a look at this: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc&data=u64 in eight benchmarks, Javascript in Google's V8 is never worse than 20 times slower than C and never uses more than 24 times as much memory. That's a far cry from the "hundreds (or thousands) of times slower than native code" you state above. And the performance wars are far from over, especially since mobile devices are still resource constrained and people keep trying to do more and more things on mobile.
But the real problem is still that skilled developers are more expensive than throwing more hardware at a problem and using easier tools. If a company could feasible sell tablets and smart phones with a huge collection of cute and creative applications written in C, fortran, and assembly, it would have been done already and that company would have taken the world by storm when it let you run 20 times as many apps each 20 times as fast on smart phones that Android doesn't even support any more. The vendors are already taking the most cost-effective path - put some brilliant minds on improving the hardware, put some brilliant minds on improving the Javascript interpreter / Java Virtual Machine / PHP Hotspot / PyPy / etc... and let the hundreds of thousands of developers not brilliant enough to do either work with easier tools.
Slashdot Mirror
To use your analogy, we're letting people with normal sight use handicap assistance dogs in the shop. They just think they need the dog, they don't. But we can't legislate a cure for delusion. The best we can do is make the test for who needs handicap assistance more strict so that only genuinely disabled people can use them.
Otherwise, every idiot that wants to bring a traveling zoo into the store has a carte blanche excuse to do it, and until someone invents reliable mind-reading equipment we have no justification for preventing it.
So if a psychiatric patient believes that God wants him to walk around waving his genitals at people, we have to allow it because of his religion?
If the answer is yes, then I'm going to announce that my soul is imperiled unless the United States government pays me a million dollars per day. It's the Church of Just Fucking Make Me Rich, and Jesus, Allah, and Joseph Smith came to me in a vision and said I had to found it or I would be damned.
Robert Heinlein had some wacky ideas, but in one of his books he has the guideline, "Thou shalt pay lip service to the prevailing religious belief of thy culture." i.e. When in Rome, act like the Romans do.
The crazy religious people are still an overwhelming majority in the US, I suspect we're at least one or two generations away from the time an atheist could be elected president. I wouldn't be surprised if most of the Presidents and Presidential candidates of the last fifty years were closet atheists who pretended to Christianity for the sake of winning the election.
Your two words "atheistic religion" is as logical as "watching television when the television is off".
If I argue that ROT13 is the ultimate unbreakable encryption scheme on Slashdot, or that Windows 95 is the most secure operating system ever created, I would get ridiculed and I would deserve to get ridiculed. Religion is no different.
The site is often friendly to people asking questions, but it's harsh to people asserting illogical ideas.
What? Have you listened to the religious folk? You'll find millions of reasonable, pleasant, even brilliant people if you engage in polite conversation about other topics. Bring up faith and they string together a series of logical fallacies that make your head spin and a supreme being that's some bizarre unknowable sadist but somehow represents all that is good in the universe. I defy you to find an exception, except maybe Buddhism - but depending upon the sect, some Buddhism is more personal philosophy than religion.
Note also that almost all war and murder before the 20th century had religious belief as a motivator for the conflict or was a secular conflict conducted by devoutly religious people. The Civil War was secular, but faithful Christians were butchering each other over a practice almost no atheist defends as moral - slavery.
It might be a better idea to arm women everywhere, and maybe put more effort into teaching men that rape is wrong and also teaching everyone to intervene when they suspect a rape is in progress. The saddest part about the rapes and gang rapes in the news these past few months in the US is the actual rapes - but the second saddest part is that other people present at the social events suspected what was happening and neither intervened nor alerted the police.
These days "agnostic" is typically interpreted as, "I don't know if god exists." The original meaning of the word is closer to: "I don't think it's possible for humans to understand in any meaningful way whether god exists." I call myself an atheist because it's simpler, but really I think (not believe) the older meaning of the word agnostic is correct.
But Charliemopps is belittling a serious problem - many Christians, Muslims, Mormons, and members of other religions are trying to inject their religious beliefs into civil law. You want to live your own life based on selective interpretation of the Bible? Fine. You want me to follow the same rules? No. That is why atheists and agnostics need to have a public presence in our modern time - to keep the people who think the creator of the universe is intensely concerned with whether they eat shellfish or what days of the week they pray from writing the laws.
For home computer users, it's far easier for someone wanting to listen to your internal network traffic to crack WEP than physically tap into your cat5 cables somewhere in the house. Listening in wirelessly takes a laptop in a car outside the home, listening to the wired network requires at a minimum a physical home invasion - obviously the person can tap your phone, coaxial cable, or fiber connection between the provider and your house, but that doesn't give them the same internal network access as physically tapping your network inside the home router.
And you can't really expect every home user, or even most home users, to go through the trouble of setting up an in-home VPN in addition to their wireless network. You have to assume that for home users, WEP was originally intended to be their complete security solution - and it was a total failure.
TKIP modifies WEP to be secure, and TKIP runs on any hardware that can run WEP.
WEP was designed to be secure, nobody would go through the trouble to invent a security protocol that they knew could be defeated by commodity hardware in under an hour. WEP was just designed poorly.
Even for companies that primarily write software, it's easy to design something that looks secure to you but in fact is trivial to defeat. WEP wireless security is inherently flawed. PPTP VPNs from Microsoft are inherently flawed, though not as badly as WEP, and Microsoft has deprecated the entire protocol. WPS wireless easy setup is flawed. The AES encryption used by Megaupload in their re-launch earlier this year was not implemented properly, and thus is useless.
The history of computing is littered with flawed attempts at designing new security protocols. As far as I can tell, the best practice is to adopt an existing open source technology that is well proven. If you're trying to do something new, you probably need to spend an unholy fortune on multiple independent audits of the system, as well as inviting people on security mailing lists to examine it, and possibly offering a bounty for discovered flaws.
Right. But nobody in the Lisp community has the authority to fix the situation - and as you noted, the community is full of people who are opposed to any such fix, so the chances of someone entering the community to fix it is small.
So the best possible solution, weak though it may be, is to create something new that just borrows strengths from Lisp but is intentionally different. Clojure is that kind of attempt at a fresh start, and it breaks some Lisp syntax (using square brackets in some cases) and intentionally does not have compatibility with the Common Lisp standard. Maybe that's more balkanization, but maybe these intentionally more different offshoots have a chance to succeed when the dialects that are closer to each other have failed.
If you read articles on Lisp dialects on Github, the sad news is that Emacs Lisp configuration files are the most popular Lisp variant. That's great for fans of Emacs, not so great for people who want to see Lisp widely adopted. Outside of those files, the two most popular Lisp dialects are Clojure and Racket - which I believe are the two versions of Lisp that are furthest from the Lisp core family.
Armed Bear Common Lisp is a full Lisp implementation on the JVM. To my knowledge its popularity is miniscule. Clojure is newer, not a standard Lisp, and it's used hundreds of times as often.
I'm a Clojure fan, sorry. :) Clojure offers many things, but I think the three most important features it adds to the standard Lisp strengths are:
1. Variables are immutable by default, though there are mechanisms for traditional mutable variables you have one extra step to use them. That makes it easier to reason about your code, without forcing every variable to be immutable like Haskell.
2. It's interoperable with Java, so aside from the relatively small Clojure standard library your extended "standard library" is the Java standard library. Plus of course you can use any of the tens of thousands of other existing Java libraries. That of course also provides Clojure with a single solution to the standard libraries question - under the hood you use java.net for networking, java.io and java.nio for IO, etc...
3. It's interoperable with Java, so the learning curve for developers and the adoption curve for tens of thousands of existing companies is much more straightforward than bringing in another Lisp dialect that's only compatible with C++, C#, Perl, Ruby, Java, etc... by using foreign function interfaces.
I think your point about multiple conflicting implementations and disputes between them is insightful. I do think that's the reason Clojure may have a better chance at mainstream adoption than any other Lisp dialect of the past 20 years.
Maybe I was lucky, the first time I tried Clojure was within the past year and the installation worked flawlessly. My biggest problem with the language is that some error messages from simple mistakes (mis-aligned parenthesis, etc..) are obtuse - I consider that an obstacle to adoption of the language. I've acquired the patience to work past errors like that, even though they drive me bonkers for the first few weeks I'm learning a new language. But that kind of thing can and will make the difference between widespread adoption and fading to obscurity in the long term.
Once you do get comfortable with Clojure, the documentation search features right in the REPL are wonderful, so if you don't remember how to do a certain thing you can often find it quickly.
With regard to libraries, Clojure of course benefits from the fact that Java's standard library is rock solid. It's full of warts and odd inconsistencies, but it's reliable.
It's interesting that you mention D. It's one of the languages I spent some time learning when I began my "anything but Java" search, and I think the language itself is brilliant - definitely a huge evolutionary step forward from C++, in my humble opinion ahead of Google's Go language. But I hadn't realized the standard library was so weak, my exploration hadn't reached that far. That's a damn shame. Andrei Alexandrescu's "The D Programming Language" book is probably the best programming language book I've ever read.
Then you and I are using different criteria to measure practicality - though I suspect my criteria line up more closely with Guido's criteria than yours.
No matter how effective a tool is, if it's not in mainstream use that's a significant mark against its practicality. Four decent Lisp developers might be able to build a particular piece of business software faster and with fewer errors than fifteen decent Python developers - but if I can't find four decent Lisp developers in the local market, I'm still going to pick Python when I start the project.
If Lisp was going to take over the world, or even just be used in as much as 10% of the software created in any given year, it would have done it already. That, I think, is the entire reason why Clojure ( and before Clojure, Scheme and Racket, https://en.wikipedia.org/wiki/Racket_(programming_language), and since Clojure, Hy http://docs.hylang.org/en/latest/ ) have been created - attempts to tweak the Lisp formula into something more palatable for the mainstream without losing any of the core features that make the language useful.
I wish Lisp and Clojure were more prevalent. Most of my work experience is with Java, and now that I've become comfortable with Lisp and Clojure in my spare time I'm chafing at the tools I have to use for work. There just aren't that many jobs around, at least outside Silicon Valley, that use either language. So I'm trying to do useful Clojure stuff in my spare time in order to have a portfolio I can show off for a Clojure shop.
But to your point, I think Guido is safe to dismiss Lisp - it's a spectacular functional language, it's one of the most well known functional languages, and at least in original and Common Lisp form it just can't get traction in the mainstream.
Good points. Thanks again for injecting a reality check across the discussion.
But in the case of GUI testing, there are so many display resolutions and graphics processors and so forth in the Android world - which is the biggest target, of course - that your GUI testing is going to be extensive regardless of native vs. web if you target Android. iOS used to have a smaller number of targets, but now it's getting bigger (if not as big as Android).
While mobile site performance is often pitiful, mobile devices are getting more powerful and web browsers are getting more efficient. Native will always trump web for performance, but for an awful lot of simple applications the difference doesn't matter and every year the subset of apps where it doesn't matter is increasing.
If the technology takes off on other platforms, Apple will follow sooner or later. They have a big portion of the market and the most profitable portion of the market, but they can't ignore a technology that the other 60% use, no matter what it is.
Often the fix you're deploying is a security fix, so the native app user rejecting the update may be avoiding an annoying UI change, but they may be opening themselves to a hack. That's still a problem and not a clear win for native.
Net's down problem is legitimate. Forgetting to renew your domain registration is effectively the same as "net's down".
With a native app, there's a much better than even chance that Apple, Google, Microsoft, or AT&T, Sprint, T-Mobile, and Verizon can pull all your data off the phone anyway. Winner: none.
Setting up your own purchase system is a hassle, but the percentage taken by Google Wallet or Amazon Checkout or whatever is far less than what you pay in the typical App Store, where they get a 30% (typically) of all transactions and in some cases forbid you from advertising a lower price outside their app store.
If you are hacked, all of the people using your application between when you are hacked and when you take down the site until it's fixed are hacked. That's not all of your users, automatically. But yes, good point.
If your web server goes down, you're in trouble. But so many applications depend upon a web service anyway, so you get the worst of both - a native app that still doesn't work correctly if the backend is not available.
With the single code base across all applications, I mean it in the sense that it's all HTLM5 plus Javascript. Obviously you're going to have custom logic in the client or server based on the specific browser and platform the client is using - or you're going to use one of the third party libraries (modernizr, etc...) to handle the differences for you.
Sure. But if it's a web app, I don't have to grant it any permissions. When my browser is closed, it's not doing anything.
I'll grant you games, I don't ever see them being less than two or three generations behind in web vs. native. But in terms of camera, Firefox is making their own HTML5 APIs for manipulating the camera in Firefox OS and I believe they're trying to make it a w3c standard. If that technology becomes mainstream, there you go.
In most cases the performance difference is from 3-10x in speed or memory. But even at 20/20, that's better than Python, Perl, Ruby, and PHP, and those languages are used all over the place. Java has great performance when run for a long time because of the optimizations the HotSpot JVM applies to long-running processes, for those it can often match C++ performance speed. But Java even under the best circumstances uses 5-50 times as much memory as C++ for similar applications. Flash is used all over the web and in many downloadable games, and I believe its performance is somewhere in line with Javascript, or worse.
That won't bring a home computer or laptop to its knees for many applications. I wouldn't use Javascript for Call of Duty 5, or a Video Editing program, but for a chat client or a music player, what difference does it make?
I wasn't responding to the original article, I was responding to SuperKendall.
But - maybe this makes me boring - the most common feature I use on my Android phone is bookmarks. I have my movie theater ticket purchase site bookmarked, the local weather site bookmarked, and a few others. I don't use many native apps. So the "performance and usability" advantage of native apps is meaningless to me, the only native app I installed is Firefox browser.
Because so much of the world relies on Javascript, the browser vendors are in a performance war and keep upping their investment in Javascript just-in-time compilation. Have a look at this: http://benchmarksgame.alioth.debian.org/u64/benchmark.php?test=all&lang=v8&lang2=gcc&data=u64 in eight benchmarks, Javascript in Google's V8 is never worse than 20 times slower than C and never uses more than 24 times as much memory. That's a far cry from the "hundreds (or thousands) of times slower than native code" you state above. And the performance wars are far from over, especially since mobile devices are still resource constrained and people keep trying to do more and more things on mobile.
But the real problem is still that skilled developers are more expensive than throwing more hardware at a problem and using easier tools. If a company could feasible sell tablets and smart phones with a huge collection of cute and creative applications written in C, fortran, and assembly, it would have been done already and that company would have taken the world by storm when it let you run 20 times as many apps each 20 times as fast on smart phones that Android doesn't even support any more. The vendors are already taking the most cost-effective path - put some brilliant minds on improving the hardware, put some brilliant minds on improving the Javascript interpreter / Java Virtual Machine / PHP Hotspot / PyPy / etc... and let the hundreds of thousands of developers not brilliant enough to do either work with easier tools.
I don't see your do-over ever happening.