Clearly client-side techniques are going to be more efficient. It's nice to know that Google has caught up with everybody else's understanding of this.
The problem is that the user can easily turn off AJAX futionality in their browser. It may not matter to Google whose business model is a bit murky, but for many businesses this is a fatal flaw.
MS was just using the model established by Netscape.
The problem is that HTML/HTTP was great for simple hypertext web sites, but really wasn't capable of handling the interactive sites we use today. Had Tim Berners-Lee had a little more vision, many of these extentions wouldn't be necessary.
Even if you're using IIS and ASP.NET it isn't really necessary to use IE and client-side JavaScript. Sure, not all ASP.NET features can be used without it, but it's not a necessity.
It seems to me you shouldn't depend on JavaScript being enabled on the client side.
"Are you addicted to the toilet? According to the Opinion Research Corporation, the odds are pretty good that you are. Their study of 4,012 adults in the twenty largest U.S. cities found that 99% of respondents start the day by going to the toilet and checking for results.
"Now you have the nerve to quote selectively and try the freshman-law-school trick of putting your misquoted words in my mouth."
You're half right. I didn't misquote you but I didn't quote everything you said either. I guess it wasn't entirely fair although I think the sentence I quoted cannot be entirely redeemed by what follows. It's also a well-known trick to make an absolute statement for effect and then water it down to CYA. Only you know if that was the case here. I'm done with Javascript vs. Python argument. You can delcare victory if you want.
My original point was that there were common activities that take place in web applications that today have to be done through JavaScript becuase HTML and HTTP didn't anticipate their usefulness. For example, performing a post back on a change to an element rather than clicking on a submit button. It would be much better if you could use an attribute to add this behavior to an element rather than having to write Javascript code (or code in any other langauge). So a new suite of standards could over this kind of functionality.
Then somebody implied skiping the browser completely and in that context I thought speed would be important and that a compiled language (I should have said a compiled implementation) would be better. I didn't say that speed was always better. Note in this context I'm not taking about merely implementing a GUI or initiating a postback, I'm talking about the entire application.
I don't have any opinion frankly about Javascript's speed in the context of today's web browsers.
"you wrote "We were talking about Javascript not Python" as if there were a difference."
So your argument is that there is no difference between Javascript and Python?
There is zero "evidence" (I invite you to produce some to the contrary) that interpreted languages are "too slow" for scripting tasks, including JS in web browsers.
Oops you used the phrase "interpreted languages" that I got dinged for. I'm not sure what you mean by "scripting tasks" so I could hardly be making any claims about them. Are those tasks that don't need to run fast?
"Sophomoric arguments of the form "compiled is always faster than interpreted, faster is always better" are false on at least two counts."
Of course I never claimed that as you well know. You have a talent for distorting arguments and setting up straw ones, but I'm tired of playing.
Clark was more of a VC and those guys don't care about the long term prospects of a company. If they can get out with a big sack of money they're happy. That's exactly what happened. There's a good chance that Netscape would have been sold even if they had retained their market share.
We weren't talking about Python Period. It doesn't matter whether it was compiled, interpreted or shredded.
OK so I can keep the CS Gods happy I'll rephrase my original point:
If we were starting from scratch, I believe it would be better to choose a language that has a compiled implementation and to use said compiled implementation instead of an interpreted implementation because at present the evidence indicates that compiled implentations run faster than the interpreted ones. JavaScript doesn't have any well-known (possibly not any) compiled implementations, so I don't think it would be a good choice.
Your conclusion that I in particular had a bad education doesn't logically follow from the statements I made or the fact that you believe your education didn't match my description.
"Additionally I will expunge all visible references to IE and Outlook (on the START menu, in the Programs menu, etc.) and ensure his default clients are set to firefox and thunderbird."
Didn't Netscape attempt to rewrite their browser in Java? If so, that's an important part of the story.
The article claims that Netscape was about to go bankrupt just before being purchased by AOL. Given the millions raised by going public this seems unlikely.
My intention wasn't to suggest that US schools were different than those in other countries, but I went to school in the US and have no basis to make claims about schools in other countries. That is why I qualified my comments with the phrase "at least in the US".
Probably because they did well in school. But school (at least in the US) wasn't designed to teach people to think, but to teach them to memorize facts and follow directions.
I'm happy that you know so much about program translation and that I afforded you the opportunity to apply that knowledge to that most noble goal of computer science: insulting someone you disagree with on Slashdot.
I will resist the temptation of implicitly insulting you by explaining what my statement meant when the meaning is quite obvious, because I believe you understood it the moment you read it.
"You've moved the goalposts. I was saying that behaviour is outside the scope of HTML and HTTP. I was not saying that behaviour is outside the scope of websites."
Actually behavior is not outside the scope of HTML and HTTP. If I click on a button in a form, the browser will perform a postback. That's behavior. If HTML included an optional attribute that allowed any element of a form to perform a postback without resorting to Javascript, it would be a behavior that would be essentially the same as clicking the button.
"No. People made simple websites. People decided that they wanted to do more with websites. This expanded the problem area."
It's a matter of opinion whether these additional capabilities should have been anticipated. But in any case you support my argument. If these additional capabilities were not part of the orginal problem area, than then those functions assigned to Javascript were not done for the purpose of good partitioning, but rather because HTML/HTTP were not capable of supporting them.
Some common scenarios that Javascript is used for would be more effectively handled declaratively. It doesn't mean that Javascript is bad, only that if you were designing everything today, you probably would allocate functionality differently.
"You said that Javascript was unsuitable because it was interpreted. I was pointing out that languages themselves are neither interpreted nor compiled, implementations are interpreted or compiled. In order to aid your understanding, I gave an example of Python, which is both compiled and interpreted."
You take a rather narrow view of computer languages. Technically you can't perform I/O in the classic C language, but it doesn't matter because the standard library suppports it. So the line between a language and its implementation is not as clear cut as you may believe. I don't find this sort of argument to be of much practical value.
If in theory a particular language can either be compiled or interpreted that's great, but implementations are required to do real work. The fact that Python is both compiled and interpreted and Javascript is only interpreted (in practice) is quite relevent to what language we might choose.
Actually, the industry was quite large in those days. Much bigger than the movie industry at that time. The problem was there were so many companies selling games that there was a glut of merchandise and the market calapsed.
Just before the first video game crash in the 80's, Mattel Electronics agreed to pay programmers a small fee for each cartridge sold. Alas, they were out of business before they paid out any (much?) money.
Slashdot Mirror
Clearly client-side techniques are going to be more efficient. It's nice to know that Google has caught up with everybody else's understanding of this.
The problem is that the user can easily turn off AJAX futionality in their browser. It may not matter to Google whose business model is a bit murky, but for many businesses this is a fatal flaw.
I mostly agree with you but I think it's best to insure that your site is the best it can be even if Javascript is disabled.
So "AJAX" functionality should be "icing on the cake" rather than the foundation for mainstream sites.
MS was just using the model established by Netscape.
The problem is that HTML/HTTP was great for simple hypertext web sites, but really wasn't capable of handling the interactive sites we use today. Had Tim Berners-Lee had a little more vision, many of these extentions wouldn't be necessary.
Even if you're using IIS and ASP.NET it isn't really necessary to use IE and client-side JavaScript. Sure, not all ASP.NET features can be used without it, but it's not a necessity.
It seems to me you shouldn't depend on JavaScript being enabled on the client side.
"Are you addicted to the toilet? According to the Opinion Research Corporation, the odds are pretty good that you are. Their study of 4,012 adults in the twenty largest U.S. cities found that 99% of respondents start the day by going to the toilet and checking for results.
"You can't have one without a shell, editor, and compiler. Period"
You mean there were no functional OS's written in assembly? That all Os's have a shell? That all OS's have editors?
You need to get out more often.
Of course, the blame must go to MCSE's .. or Canada.
"Now you have the nerve to quote selectively and try the freshman-law-school trick of putting your misquoted words in my mouth."
You're half right. I didn't misquote you but I didn't quote everything you said either. I guess it wasn't entirely fair although I think the sentence I quoted cannot be entirely redeemed by what follows. It's also a well-known trick to make an absolute statement for effect and then water it down to CYA. Only you know if that was the case here. I'm done with Javascript vs. Python argument. You can delcare victory if you want.
My original point was that there were common activities that take place in web applications that today have to be done through JavaScript becuase HTML and HTTP didn't anticipate their usefulness. For example, performing a post back on a change to an element rather than clicking on a submit button. It would be much better if you could use an attribute to add this behavior to an element rather than having to write Javascript code (or code in any other langauge). So a new suite of standards could over this kind of functionality.
Then somebody implied skiping the browser completely and in that context I thought speed would be important and that a compiled language (I should have said a compiled implementation) would be better. I didn't say that speed was always better. Note in this context I'm not taking about merely implementing a GUI or initiating a postback, I'm talking about the entire application.
I don't have any opinion frankly about Javascript's speed in the context of today's web browsers.
"you wrote "We were talking about Javascript not Python" as if there were a difference."
So your argument is that there is no difference between Javascript and Python?
There is zero "evidence" (I invite you to produce some to the contrary) that interpreted languages are "too slow" for scripting tasks, including JS in web browsers.
Oops you used the phrase "interpreted languages" that I got dinged for. I'm not sure what you mean by "scripting tasks" so I could hardly be making any claims about them. Are those tasks that don't need to run fast?
"Sophomoric arguments of the form "compiled is always faster than interpreted, faster is always better" are false on at least two counts."
Of course I never claimed that as you well know. You have a talent for distorting arguments and setting up straw ones, but I'm tired of playing.
If by "hacker" you mean "cracker" than I don't think expertise is the differentiating factor, it's criminal intent.
Clark was more of a VC and those guys don't care about the long term prospects of a company. If they can get out with a big sack of money they're happy. That's exactly what happened. There's a good chance that Netscape would have been sold even if they had retained their market share.
By "compiled" I mean "converted to machine code" the primary meaning of the word for the last 50 years.
We weren't talking about Python Period. It doesn't matter whether it was compiled, interpreted or shredded.
OK so I can keep the CS Gods happy I'll rephrase my original point:
If we were starting from scratch, I believe it would be better to choose a language that has a compiled implementation and to use said compiled implementation instead of an interpreted implementation because at present the evidence indicates that compiled implentations run faster than the interpreted ones. JavaScript doesn't have any well-known (possibly not any) compiled implementations, so I don't think it would be a good choice.
Now was that sufficiently pedantic for you?
Your conclusion that I in particular had a bad education doesn't logically follow from the statements I made or the fact that you believe your education didn't match my description.
"Additionally I will expunge all visible references to IE and Outlook (on the START menu, in the Programs menu, etc.) and ensure his default clients are set to firefox and thunderbird."
Good work, OSS thought policeman!
Didn't Netscape attempt to rewrite their browser in Java? If so, that's an important part of the story.
The article claims that Netscape was about to go bankrupt just before being purchased by AOL. Given the millions raised by going public this seems unlikely.
My intention wasn't to suggest that US schools were different than those in other countries, but I went to school in the US and have no basis to make claims about schools in other countries. That is why I qualified my comments with the phrase "at least in the US".
As someone who posts to Slashdot fairly often, I know I've been guilty of that one from time to time.
Revealing that might also reveal my secret identify.
Anyway, I interpret your question to mean you disagree with me. If so, what percentage of your time in elementary school was devoted to reasoning?
considered smart?
Probably because they did well in school. But school (at least in the US) wasn't designed to teach people to think, but to teach them to memorize facts and follow directions.
I'm happy that you know so much about program translation and that I afforded you the opportunity to apply that knowledge to that most noble goal of computer science: insulting someone you disagree with on Slashdot.
I will resist the temptation of implicitly insulting you by explaining what my statement meant when the meaning is quite obvious, because I believe you understood it the moment you read it.
"You've moved the goalposts. I was saying that behaviour is outside the scope of HTML and HTTP. I was not saying that behaviour is outside the scope of websites."
Actually behavior is not outside the scope of HTML and HTTP. If I click on a button in a form, the browser will perform a postback. That's behavior. If HTML included an optional attribute that allowed any element of a form to perform a postback without resorting to Javascript, it would be a behavior that would be essentially the same as clicking the button.
"No. People made simple websites. People decided that they wanted to do more with websites. This expanded the problem area."
It's a matter of opinion whether these additional capabilities should have been anticipated. But in any case you support my argument. If these additional capabilities were not part of the orginal problem area, than then those functions assigned to Javascript were not done for the purpose of good partitioning, but rather because HTML/HTTP were not capable of supporting them.
Some common scenarios that Javascript is used for would be more effectively handled declaratively. It doesn't mean that Javascript is bad, only that if you were designing everything today, you probably would allocate functionality differently.
"You said that Javascript was unsuitable because it was interpreted. I was pointing out that languages themselves are neither interpreted nor compiled, implementations are interpreted or compiled. In order to aid your understanding, I gave an example of Python, which is both compiled and interpreted."
You take a rather narrow view of computer languages. Technically you can't perform I/O in the classic C language, but it doesn't matter because the standard library suppports it. So the line between a language and its implementation is not as clear cut as you may believe. I don't find this sort of argument to be of much practical value.
If in theory a particular language can either be compiled or interpreted that's great, but implementations are required to do real work. The fact that Python is both compiled and interpreted and Javascript is only interpreted (in practice) is quite relevent to what language we might choose.
battery or the external car battery?
Actually, the industry was quite large in those days. Much bigger than the movie industry at that time. The problem was there were so many companies selling games that there was a glut of merchandise and the market calapsed.
Just before the first video game crash in the 80's, Mattel Electronics agreed to pay programmers a small fee for each cartridge sold. Alas, they were out of business before they paid out any (much?) money.