I think you missed the "perhaps" in my original post. Yes, Google has the resources, and if they are interested, perhaps they will push UI design forward, etiher by hiring really great UI people, as they have hired bright minds in the past, or stealing Apple's ideas and improving them for netbook use.
Modern UIs still have a lot of baggage from the desktop metaphor. Honestly, I don't see how windowing systems have changed fundamentally since that metaphor was in heavy usage, but we can agree to disagree. The fact is that to move forward in UI design, concepts need to built again from the ground up. Windowing systems are non-optimal by nature.
Those are good points, definitely. I don't think these things make marijuana, in and of itself, harmful. Abuse is certainly a problem with almost anything, but a reasonable adult will have no problem controlling their use of intoxicants -- especially those that are only mildly physically addictive, if at all.
No, not so far today! In so much as marijuana is not particularly addictive, if at all, and that there is no known LD-50 for it, and the fact that it has no long term effects on your organs (you don't have to smoke it), etc., etc. Yes. It is safe, or at least safe enough that the government has no business prohibiting it, especially given that any harm marijuana may cause to its users is rendered moot by the harm caused by prohibition. For instance the Mexican cartels make somewhere between 60% and 75% of their money selling marijuana.
Anyway, if you have any reputable studies showing that marijuana is harmful, when ingested through other means than smoking, please share. It's been about five years since I extensively researched the medical literature regarding it. However, I am relatively certain that there have been no significant breakthroughs that would suggest it is any more harmful than our other chemical indulgences.
What... makes you think Google can give UI design some "real progress"?
Billions of dollars and thousands of man-hours. If they are experimenting with novel UI design elements, as it says in TFS, it may be that they come up with something new and groundbreaking, or at least steal the best ideas from others (Apple) and improve on them.
Windowing systems a metaphor to desks and file cabinets? WTH?
LOL. First of all, the major UIs go so far as to call the "main screen" (or however you want to call it) the "desktop." Furthermore, windows are a metaphor for papers being moved around on that desktop. Hierarchical file systems are based on filing cabinets -- the major difference being that without any physical limitations, digital folders/directories may contain any number of files and sub-folders/sub-directories.
You can read more here, if you feel the Hell like it.
If the UI is on a netbook instead of a tablet (that isn't a PC) or a cellphone, that may be progress enough to get the ball rolling with other people following them.
We do need to end the War on (all) Drugs. Legalize the ones, such as marijuana, that are relatively harmless. Decriminalizing everything else and making the punishment drug treatment, along with the legalization of relatively benign substances, would reduce the power of organized crime in the Americas to ashes within a year or two.
Perhaps there will be real progress in UI design now that Google is putting its resources toward that goal. I hope windowing systems die soon. There has to be a better design than a metaphor to desks and file cabinets...
"Fly over country" is a really mean thing to say. Sure, there aren't the largest centers of culture in the vast swath between the coasts, but there are metropolises of some merit. And while I'm not trying to equate mid-US small towns with Bath or Florence, it is not as if there is not a rich culture and history around here. If less exciting socially than more cultivated regions, there is certainly merit in the rustic fare, as well as the many other gifts oft overlooked.
All I will say is that if I am changing subjects, then you are doing so double. And verging on support of eugenics, so... yeah. That's the end of that.
I guess it comes down to whether you believe that man's cultural differences are important and beautiful or you believe that we should pretend everyone is the same.
"White pride" isn't inherently racist -- although I sincerely doubt that anyone using that phrase to describe themselves or their group wouldn't be a racist. The term has a very bad connotation, because of the people who use it to describe themselves. If you say something exactly the same, such as "I am white and I am proud of my heritage," it is obviously a less emotionally charged statement. There's also the little thing of white people, as a race, having no history of persecution in America.
Except that no one is saying they are funny because they are genetically Saudis. (Would that even have any basis in reality? Are Saudis their own "race?") Cultures have many differences between each other, and that is a beautiful thing -- and that is what is being discussed.
On the other hand, I don't know why I take the time to reply to obvious, anonymous trolls:)
In so much as a virtual machine mimics, more or less, a hardware machine, there is no reason one could not be developed to do all these things in the context of the browser (which is already more or less a standardized application platform). From the response you quote:
Unfortunately, the bitcode is non-portable because it has architecture-specific constants from C/C++ header files baked in (not to mention linkage against system libraries).
This wouldn't be an issue on browsers, as you would only be targeting one architecture: the browser. I'm not saying the LLVM could do all of these things: I'm saying that it is very close to what I am talking about. Of course there is not something that does these things already. I am talking about the future.
But I digress. I am not asking you to work on these ideas. The fact that you won't consider their merit as the web continues to evolve is not a reason to continue this discussion.
You are assuming that JavaScript is the language best suited for the web -- that is not true. I'm not talking about what is probable to happen. That's a fine way to think for the present, but you are really missing the big picture here. JavaScript is already being compiled to byte-code, in many implementations, with great success. The idea that this byte-code couldn't ever be redesigned is quite a bit short-sighted. The idea that a fast VM that supports many different languages couldn't be used in the browser is just nonsense. In so much as a VM more or less does the same thing as hardware machine does, it should be clear that a VM can support multiple languages just fine. Take a look at LLVM or other similar projects. And, there are many variegated types of languages that successfully target VMs -- whether JVM, the CLR, or otherwise. That's not even really an issue, as any VM designed for use in the browser could be made to play nice with many languages by not requiring garbage collection, supporting tail calls, etc.
I don't really see a good solution here, and JavaScript seems like a reasonable trade-off.
I'm not disagreeing with you, but my point is that is a far from optimal approach. HTML 5 and CSS 3 are truly advancing the state of the web; it's time that the code aspect of the web took similarly large steps forward. GWT is just a compromise to overcome the shortfalls of JavaScript. That's fine if you don't care to dream.
I'm saying it would nice to have a choice to program for the web in whatever language you want; it would be nice to be able to program in anything that has a compiler that targets "the web," and to have your code compile directly to a standardized byte-code, instead of compiling to JavaScript. There's really no reason that JavaScript should be the only language supported by browsers. Using a byte-code based VM would negate the need for browsers to support more than one language: anyone could create compilers that target that byte-code, and we could use whatever language we want.
The reasons for using DSLs, functional languages, or other OO languages are as numerous for the web as they are for any other application platform. And I'll say again, I like JavaScript, especially with jQuery, but JavaScript should not be the only choice when developing applications that run in a standard browser (without plug-ins).
The nice thing about an assembly language for the web is that it could compile to byte-code run by a standardized virtual machine (which can be further abstracted to be a compatible, thin layer between the language and the processor). You are right - browsers running native code is a horrible idea, and a step backwards. JavaScript is a fine language, and jQuery makes it a dream to write JS code, but we should have more options than that, especially where other niche languages have an advantage. We could start coding the web in whatever language we choose - be it a functional language, or a domain-specific language, or a language designed for multiple cores/processors, etc. The latter could be unnecessary if the compiler were advanced enough to support concurrency automatically. I am not a compiler designer, but from what I can tell that has been a rather elusive goal with most traditional OO and procedural languages.
Even Python, as much as I love to write in it, is the wrong answer for the web. Really, we need to have a standardized byte-code/virtual machine implemented (gasp, identically!) over all browsers:) Then for your standard situations you could choose whatever you wanted -- Python, JavaScript, etc. And for applications where it was advisable, you could pick Erlang or Haskell, etc., or hell, even Logo, if you wanted! It wouldn't matter! We'd be free to create compiler for whatever language we chose that target that virtual machine.
Projects such as SquirrelFish are great, because I think they will show the world exactly what the benefits of a virtual machine for the web will be. Once projects like it are incorporated into the browser, it is a relatively small step to abstract away from JavaScript and support any language that has a compiler targeting this VM. If you are interested there is a very interesting discussion on Lambda that addressed this and similar projects, and the trade-offs and advantages of different JIT implementations:)
I'm talking about byte-code (virtual machines). Not compiling to native code that runs in a browser (and requires a plug-in to do so). Google Native Client is a step in the wrong direction, IMHO. Native apps are native apps. The web should be, ideally, a processor and OS neutral framework for development... and I don't even want to think of the security issues that a wide-spread adoption of running native code in the browser would bring -- just look at ActiveX. What would be best is a standard that truly separates data, presentation, and code. It should be one that is designed with that specifically in mind. A virtual machine/byte-code that is designed specifically to work with well-defined data and presentation layers would advance that goal by leaps and bounds. CSS 3 and HTML 5 are moving the web forward, in many important ways, but the method for interacting with the data and presentation layers of the web is stuck in 1999.
We need something as inventive and world-changing as the move from FTP/Gopher to HTTP.
Indeed. I am all for the idea of separating further in the browser: design, code, and data, but moving that way should be moving away from JS as the de facto language of the web, not increasing reliance on a poorly applied language. JS is not well designed for its purpose as the programming language of the web, and certainly not implemented in a standard way. Don't get me wrong, I have grown to love JavaScript, it is very nice to code in if you are rigorous with what subset of it you use, and especially with jQuery it is a very nice environment to program for, if not a very efficient or reliable one.
We should be moving towards some kind of assembly language for the web, something that compiles to byte-code. But if JavaScript is still around then, JS should be compiling to that byte code, not higher level languages compiling to JS. As a web developer, I would really like to see more languages supported in the browser, especially domain specific languages, and compiling to some sort of web-specific byte code is the way to go there.
Of course, whatever we can convince the browser makers to better in that regard, is better than nothing -- including compiling to JS, IFF that has to be an intermediary step.
Slashdot Mirror
I may or may not be right, but wouldn't putting species on that list be part of the reason they haven't gone extinct?!
That marijuana is harmless or that you are high? ;)
I think you missed the "perhaps" in my original post. Yes, Google has the resources, and if they are interested, perhaps they will push UI design forward, etiher by hiring really great UI people, as they have hired bright minds in the past, or stealing Apple's ideas and improving them for netbook use.
Modern UIs still have a lot of baggage from the desktop metaphor. Honestly, I don't see how windowing systems have changed fundamentally since that metaphor was in heavy usage, but we can agree to disagree. The fact is that to move forward in UI design, concepts need to built again from the ground up. Windowing systems are non-optimal by nature.
Those are good points, definitely. I don't think these things make marijuana, in and of itself, harmful. Abuse is certainly a problem with almost anything, but a reasonable adult will have no problem controlling their use of intoxicants -- especially those that are only mildly physically addictive, if at all.
No, not so far today! In so much as marijuana is not particularly addictive, if at all, and that there is no known LD-50 for it, and the fact that it has no long term effects on your organs (you don't have to smoke it), etc., etc. Yes. It is safe, or at least safe enough that the government has no business prohibiting it, especially given that any harm marijuana may cause to its users is rendered moot by the harm caused by prohibition. For instance the Mexican cartels make somewhere between 60% and 75% of their money selling marijuana.
Anyway, if you have any reputable studies showing that marijuana is harmful, when ingested through other means than smoking, please share. It's been about five years since I extensively researched the medical literature regarding it. However, I am relatively certain that there have been no significant breakthroughs that would suggest it is any more harmful than our other chemical indulgences.
What ... makes you think Google can give UI design some "real progress"?
Billions of dollars and thousands of man-hours. If they are experimenting with novel UI design elements, as it says in TFS, it may be that they come up with something new and groundbreaking, or at least steal the best ideas from others (Apple) and improve on them.
Windowing systems a metaphor to desks and file cabinets? WTH?
LOL. First of all, the major UIs go so far as to call the "main screen" (or however you want to call it) the "desktop." Furthermore, windows are a metaphor for papers being moved around on that desktop. Hierarchical file systems are based on filing cabinets -- the major difference being that without any physical limitations, digital folders/directories may contain any number of files and sub-folders/sub-directories. You can read more here, if you feel the Hell like it.
If the UI is on a netbook instead of a tablet (that isn't a PC) or a cellphone, that may be progress enough to get the ball rolling with other people following them.
We do need to end the War on (all) Drugs. Legalize the ones, such as marijuana, that are relatively harmless. Decriminalizing everything else and making the punishment drug treatment, along with the legalization of relatively benign substances, would reduce the power of organized crime in the Americas to ashes within a year or two.
Perhaps there will be real progress in UI design now that Google is putting its resources toward that goal. I hope windowing systems die soon. There has to be a better design than a metaphor to desks and file cabinets...
"Fly over country" is a really mean thing to say. Sure, there aren't the largest centers of culture in the vast swath between the coasts, but there are metropolises of some merit. And while I'm not trying to equate mid-US small towns with Bath or Florence, it is not as if there is not a rich culture and history around here. If less exciting socially than more cultivated regions, there is certainly merit in the rustic fare, as well as the many other gifts oft overlooked.
Yeah, fun place. The glass blowing demonstration was really cool. Some of it's pretty kitschy, but oh well.
All I will say is that if I am changing subjects, then you are doing so double. And verging on support of eugenics, so... yeah. That's the end of that.
So what you're saying, if I understand...
Well sorry, no you don't.
"White pride" isn't inherently racist -- although I sincerely doubt that anyone using that phrase to describe themselves or their group wouldn't be a racist. The term has a very bad connotation, because of the people who use it to describe themselves. If you say something exactly the same, such as "I am white and I am proud of my heritage," it is obviously a less emotionally charged statement. There's also the little thing of white people, as a race, having no history of persecution in America.
I know, that whole reading comprehension thing is so tricky for you sometimes.
Or Jordanians even... heh.
Except that no one is saying they are funny because they are genetically Saudis. (Would that even have any basis in reality? Are Saudis their own "race?") Cultures have many differences between each other, and that is a beautiful thing -- and that is what is being discussed.
:)
On the other hand, I don't know why I take the time to reply to obvious, anonymous trolls
Unfortunately, the bitcode is non-portable because it has architecture-specific constants from C/C++ header files baked in (not to mention linkage against system libraries).
This wouldn't be an issue on browsers, as you would only be targeting one architecture: the browser. I'm not saying the LLVM could do all of these things: I'm saying that it is very close to what I am talking about. Of course there is not something that does these things already. I am talking about the future.
But I digress. I am not asking you to work on these ideas. The fact that you won't consider their merit as the web continues to evolve is not a reason to continue this discussion.
I don't really see a good solution here, and JavaScript seems like a reasonable trade-off.
I'm not disagreeing with you, but my point is that is a far from optimal approach. HTML 5 and CSS 3 are truly advancing the state of the web; it's time that the code aspect of the web took similarly large steps forward. GWT is just a compromise to overcome the shortfalls of JavaScript. That's fine if you don't care to dream.
I'm saying it would nice to have a choice to program for the web in whatever language you want; it would be nice to be able to program in anything that has a compiler that targets "the web," and to have your code compile directly to a standardized byte-code, instead of compiling to JavaScript. There's really no reason that JavaScript should be the only language supported by browsers. Using a byte-code based VM would negate the need for browsers to support more than one language: anyone could create compilers that target that byte-code, and we could use whatever language we want.
The reasons for using DSLs, functional languages, or other OO languages are as numerous for the web as they are for any other application platform. And I'll say again, I like JavaScript, especially with jQuery, but JavaScript should not be the only choice when developing applications that run in a standard browser (without plug-ins).
Can you give an example?
http://en.wikipedia.org/wiki/Domain-specific_language
The nice thing about an assembly language for the web is that it could compile to byte-code run by a standardized virtual machine (which can be further abstracted to be a compatible, thin layer between the language and the processor). You are right - browsers running native code is a horrible idea, and a step backwards. JavaScript is a fine language, and jQuery makes it a dream to write JS code, but we should have more options than that, especially where other niche languages have an advantage. We could start coding the web in whatever language we choose - be it a functional language, or a domain-specific language, or a language designed for multiple cores/processors, etc. The latter could be unnecessary if the compiler were advanced enough to support concurrency automatically. I am not a compiler designer, but from what I can tell that has been a rather elusive goal with most traditional OO and procedural languages.
Even Python, as much as I love to write in it, is the wrong answer for the web. Really, we need to have a standardized byte-code/virtual machine implemented (gasp, identically!) over all browsers :) Then for your standard situations you could choose whatever you wanted -- Python, JavaScript, etc. And for applications where it was advisable, you could pick Erlang or Haskell, etc., or hell, even Logo, if you wanted! It wouldn't matter! We'd be free to create compiler for whatever language we chose that target that virtual machine.
:)
Projects such as SquirrelFish are great, because I think they will show the world exactly what the benefits of a virtual machine for the web will be. Once projects like it are incorporated into the browser, it is a relatively small step to abstract away from JavaScript and support any language that has a compiler targeting this VM. If you are interested there is a very interesting discussion on Lambda that addressed this and similar projects, and the trade-offs and advantages of different JIT implementations
I'm talking about byte-code (virtual machines). Not compiling to native code that runs in a browser (and requires a plug-in to do so). Google Native Client is a step in the wrong direction, IMHO. Native apps are native apps. The web should be, ideally, a processor and OS neutral framework for development... and I don't even want to think of the security issues that a wide-spread adoption of running native code in the browser would bring -- just look at ActiveX. What would be best is a standard that truly separates data, presentation, and code. It should be one that is designed with that specifically in mind. A virtual machine/byte-code that is designed specifically to work with well-defined data and presentation layers would advance that goal by leaps and bounds. CSS 3 and HTML 5 are moving the web forward, in many important ways, but the method for interacting with the data and presentation layers of the web is stuck in 1999.
We need something as inventive and world-changing as the move from FTP/Gopher to HTTP.
Indeed. I am all for the idea of separating further in the browser: design, code, and data, but moving that way should be moving away from JS as the de facto language of the web, not increasing reliance on a poorly applied language. JS is not well designed for its purpose as the programming language of the web, and certainly not implemented in a standard way. Don't get me wrong, I have grown to love JavaScript, it is very nice to code in if you are rigorous with what subset of it you use, and especially with jQuery it is a very nice environment to program for, if not a very efficient or reliable one.
We should be moving towards some kind of assembly language for the web, something that compiles to byte-code. But if JavaScript is still around then, JS should be compiling to that byte code, not higher level languages compiling to JS. As a web developer, I would really like to see more languages supported in the browser, especially domain specific languages, and compiling to some sort of web-specific byte code is the way to go there.
Of course, whatever we can convince the browser makers to better in that regard, is better than nothing -- including compiling to JS, IFF that has to be an intermediary step.