we should be pushing browser makers to allow scripting to be installed via plug-ins rather than being native to the browser
This sounds like an advertisement for Silverlight or Flash. ASAIK, Silverlight is supposed to support many languages including VB.NET, C#, Python, and Ruby.
No thank you. The scripting engine should be native to the web browser. The last thing I want is to author a page that requires a 10 MB download and where every HTML DOM manipulation requires a cross-apartment threading call.
By the time JavaScript 2.0 is available in nearly all browsers you find in the wild, there will already be a JavaScipt 4.0 spec out and you'll be able to write this exact comment with the dates and browser versions updated.
The reason why adoption is slow is because the current system, though not perfect, works. IMHO, there is no compelling reason to replace the script engines in the current crop of web browsers.
wouldn't it be easier to use Ruby for the client-side scripting as well as the server-side?
Not to me. My brain is big enough to know and work in more than one language. Actually, I prefer that the client side and the server side programming languages are different. I am less likely to confuse my server side coding from my client side coding. It is a common mistake to do that. For example, expecting a server side variable to be available to client side code without any additional coding.
Also, there are some real technical gaps to the story.
How can this AI that "operates on what has been said to be the most powerful university-based supercomputing system in the world" be in SL? Has Linden Labs released a public API where you can interact with their network using software that you have written and running on your machine? Did they just hack the open source viewer that LL makes available? From the above quote of that article, I can only assume that Eddie is not a fancy chatbot written in Linden Script Language because then he would be running in the SL network and not in a university network.
Obviously the ludites^H^H^H^H^H^Hate adopters would frame their reluctance as risk aversion. As any entrepreneur will tell you "no risk, no reward." In the case of the marketplace, late adoption can have high opportunity costs as it is very typical that the ones who come into a market first get the highest share of that market.
Snide comment aside, I really don't mean to put down the late adopters. Everyone has a different comfort zone in the risk/reward spectrum. This notion of diffusion of innovation has been around for years and popularized by the book Crossing the Chasm. I recently blogged on a related topic about getting to market quickly with your software product.
People don't want to have to download third party programs to do what they consider basic tasks, so providers fall back to protocols that have wide support (HTTP/FTP)
If memory serves, the basic FTP tool that comes on MS-Windows has a Command Line Interface. IMHO, most computer users, who are not using SFTP, would prefer to download and install a third party program than to use a CLI. IE does support FTP but most users won't know how to FTP with IE since you have to add your username and password to the URL.
If providers were all that concerned with an authenticating, secure, yet convenient file sharing capability, then they would be using an HTTPS based technology.
The phrase believe in astrology is fairly vague. Some people believe that astrology is the claim that your personality depends primarily on the date and hour of your birth. However, other people believe that astrology is a system of personality classification that was formed during a time when people were preoccupied with the use of the configuration of stars in the sky as a sort of mnemonic device for teaching and retaining culturally relevant stories.
Astrology was invented a long time ago so it is suspect because of the lack of cultural relevancy with current times. A more recent, and relevant, personality classification system is MBTI.
It is not unusual to attempt to teach a concept in terms of a more popular concept in order to sell that concept to a larger audience. All kinds of real world events and concepts get analogized to popular movies such as Star Wars and Lord of the Rings. In the hey day of astrology, the stars were in the sky. Today, those same "stars" are in Hollywood.
Astrology is not a religion and, what we now call Greek Mythology, has long been dead as a religion. So, the question of whether or not you can be compatible with someone who believes in astrology requires further investigation.
My guess is that he's talking about ruby on rails, because it's got a lot of hype and it's short on people with the necessary skill set. My answer in that instance would be, don't go with a young platform in the first place. Don't buy into hype until it's so mature that it doesn't have any hype, just a good solid list of pros and cons.
The shortage of RoR developers after years of buzz and hype is interesting. I ran across this phenomenon last year and blogged about it.
I had a grudge against my schooling for teaching mostly theory and hardly any practical information.
There's an old quote that goes something like this. Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime. Computer science is a lot like that fish. If all you learn in school is how to use the current crop of Microsoft developer tools, then the shelf life of your degree will be about five years. However, if you learn the fundamental basics of computer science, then you will have developed the cognitive framework in your mind for easily, almost effortlessly, learning the long list of new programming languages and tools that you will inevitably encounter in your career. That is why universities should focus on the basics and not on the toolset du jour in the workplace.
There's another reason why universities should avoid Microsoft developer tools. Those tools are focused on productivity and not on learning. So, there are all these code wizards that generate tons of boilerplate for you. This may jump start your project but you end up not really developing any understanding of what the wizard generates for you. The typical OSS approach is to avoid wizards and put the productivity boosting features in the software architecture itself.
Re:"How will you use XML in years to come?"
on
The Future of XML
·
· Score: 1
JSON is great for AJAX where XML is clunky and a little bit slower
I used to believe this until I started the web2newsportal project whose client component is a pure AJAX web app. The prototype javascript library and getElementsByTagName does a lot to remove the clunkiness of XML. Also, I am uncomfortable with the script injection vulnerabilities of JSON.
This is not a technology problem, it is a symptom of the stress that this company is experiencing. Large reply-to chains are a CYA strategy. People tend to use this strategy when they are feeling threatened about their employment status.
Seek out the root cause of this stress. Eliminate or mitigate that cause and the email etiquette problems will go away all by themselves.
Command and Control has to be in-house; however, project oriented duties can most certainly be out-sourced on a case-by-case basis.
Why does CnC have to be in-house? The short answer is conflict of interest. A consultant or employee of an out-sourcing company represents the business interests of his or her company and not yours.
Why should project oriented duties be considered for out-sourcing on a case-by-case basis? Some duties already dovetail nicely with the company's core competency. In which case, you would have lower TCO and shorter ROI by going in-house. Otherwise, you should submit a RFP and pick the vendor whose responses, mediated through the filter of in-house expertise, indicate the lowest TCO and shortest ROI.
Google, Yahoo, Microsoft, Apple - all using ajax in one form or another in their web applications
Three of those four vendors have published their own AJAX libraries for outside consumption. This accelerates adoption which is important from the standpoint of going mainstream.
...can't speak to Silverlight...design theory of ajax combined with a good JS api...makes it a much more maintainable and IMHO a nice way to build interactive web apps.
I have not used silverlight either. Those whom I have spoken with about it are jazzed about it because you don't have to use java script as the programming language. IMHO, there are serious problems with java script. Not that there's really a problem with the language itself. Rather, the problems show up in how the code engines are implemented. I have gone into more detail about this here. Good programmers can live with these shortcomings either by rendering most of the GUI via HTML and using java script only lightly (i.e. validating event handlers) or by using good libraries and debuggers.
Most of these questions appear to me to be either leading questions, whose intent is to foment desire in the questioners product(s) and/or service(s), or marketing questions.
Some of the questions are legit, however. For example, those questions concerning security, performance, unit testing, and analytics.
With regards to the question about which framework to choose, I have posted my favorites here.
To me, the term scripting has nothing to do with the level of abstraction. Rather, it is more about whether or not the source is directly interpreted or compiled into an intermediate form. Having said that, I must admit that it would be awfully silly to create a low level language that is interpreted.
From most of the languages that he lists, it looks to me that what he is really talking about are Dynamic Scripting Languages. Scripting languages that are also dynamic provide a lot of flexibility and can genuinely be categorized as different from static languages in an interesting way. I have blogged on this recently as part of a larger article on OSS.
Plone is great if it is a good fit between the requirements and developing custom document types within a CMS framework. The architecture is highly layered. The low level way of developing under plone has a non-trivial learning curve to it. The high level way is to use what is known as plone archetypes which makes it really easy to create custom document types. The skinning of the custom types becomes very easy using Zope's METAL technology which is a very cool page templating system.
So we should fix GET and POST so that they can reload only a subset of a page.
Not to split hairs but, technically speaking, the major browser implementations of GET and POST are not broken. There is nothing in the spec about overlaying the response from either into any arbitrary part of a DOM tree specified by an XPATH or XQUERY expression.
I think that it would be easier from a developer perspective here in 2007 to just code some java script than it would be to change something as fundamental as RFC 2616 and to rewrite every web browser in existence to accommodate that.
You have proposed that the web browser eliminates the running of any script or program client side. Barring obnoxious advertising, the reason why java script (or, more precisely, AJAX) is compelling is that the screen repaint from a traditional HTTP GET or POST reloads the entire screen. This "flash" is disorienting to the end user and can break up their natural flow.
I have recently blogged on this subject in my Top OSS for Coders article.
I use GSview. Is that vulnerable to this backdoor exploit? I suspect that it is not because I don't believe that this PDF viewer does anything special with URLs.
Let me see if I am getting this straight. You wrote a java script app that makes 1500 XHRs and keeps appending data to the end of the page and you are complaining about how FF is handling that. Is that your claim more or less? Here is my reaction.
If you need to populate the GUI with 1500 pieces of data, why not code your server side such that you make 1 XHR to get all 1500 pieces? You performance will improve with fewer round trips.
Any GUI that has 1500 pieces of data on it is way too complex. Consider redesigning the GUI to present less amounts of more relevant data to the user. This is called progressive disclosure and it is a good thing for improving usability. No one is going to be able to cognitively consider 1500 pieces of data simultaneously.
That fact that FF doesn't handle well such poorly designed and ill conceived GUI doesn't really bother me. In fact, the only improvement I could wish for FF is that it wouldn't handle that kind of application at all. Think of it as a bandwidth and eyeball saving feature.
This is just a guess but I would say that OO has about 85% of what MSO has. This is not really a problem because us mere mortals use only about 50% of what MSO has anyway.
As far as the retraining issue is concerned, I don't see that as a big barrier either. There is so much difference between versions of MSO, that users who need to be trained on office productivity software, will most likely need to be retrained on each version of MSO anyway. If you have to incur the costs of retraining every three years no matter what, then what difference does it make whether or not you are retraining on MSO or OO?
this is of course what Second Life does... everyone is in the same world
Although it is true that there is no end user experience of selecting a world, my guess is that it is still a shard based architecture based on location within the world. I base that guess on the observation that object rendering and latency seems to be dependent on the number of people and objects in an area. A densely crowded area has much more lag then a sparely populated area. It is not dependent, however, on how many users are currently logged in to the world.
It seems to me that SL is multi-shard but you don't explicitly select the shard. Moving from one part of the world to another may move you to a different shard.
Slashdot Mirror
This sounds like an advertisement for Silverlight or Flash. ASAIK, Silverlight is supposed to support many languages including VB.NET, C#, Python, and Ruby.
No thank you. The scripting engine should be native to the web browser. The last thing I want is to author a page that requires a 10 MB download and where every HTML DOM manipulation requires a cross-apartment threading call.
By the time JavaScript 2.0 is available in nearly all browsers you find in the wild, there will already be a JavaScipt 4.0 spec out and you'll be able to write this exact comment with the dates and browser versions updated.The reason why adoption is slow is because the current system, though not perfect, works. IMHO, there is no compelling reason to replace the script engines in the current crop of web browsers.
wouldn't it be easier to use Ruby for the client-side scripting as well as the server-side?Not to me. My brain is big enough to know and work in more than one language. Actually, I prefer that the client side and the server side programming languages are different. I am less likely to confuse my server side coding from my client side coding. It is a common mistake to do that. For example, expecting a server side variable to be available to client side code without any additional coding.
Also, there are some real technical gaps to the story.
How can this AI that "operates on what has been said to be the most powerful university-based supercomputing system in the world" be in SL? Has Linden Labs released a public API where you can interact with their network using software that you have written and running on your machine? Did they just hack the open source viewer that LL makes available? From the above quote of that article, I can only assume that Eddie is not a fancy chatbot written in Linden Script Language because then he would be running in the SL network and not in a university network.
Obviously the ludites^H^H^H^H^H^Hate adopters would frame their reluctance as risk aversion. As any entrepreneur will tell you "no risk, no reward." In the case of the marketplace, late adoption can have high opportunity costs as it is very typical that the ones who come into a market first get the highest share of that market.
Snide comment aside, I really don't mean to put down the late adopters. Everyone has a different comfort zone in the risk/reward spectrum. This notion of diffusion of innovation has been around for years and popularized by the book Crossing the Chasm. I recently blogged on a related topic about getting to market quickly with your software product.
If memory serves, the basic FTP tool that comes on MS-Windows has a Command Line Interface. IMHO, most computer users, who are not using SFTP, would prefer to download and install a third party program than to use a CLI. IE does support FTP but most users won't know how to FTP with IE since you have to add your username and password to the URL.
If providers were all that concerned with an authenticating, secure, yet convenient file sharing capability, then they would be using an HTTPS based technology.
The phrase believe in astrology is fairly vague. Some people believe that astrology is the claim that your personality depends primarily on the date and hour of your birth. However, other people believe that astrology is a system of personality classification that was formed during a time when people were preoccupied with the use of the configuration of stars in the sky as a sort of mnemonic device for teaching and retaining culturally relevant stories.
Astrology was invented a long time ago so it is suspect because of the lack of cultural relevancy with current times. A more recent, and relevant, personality classification system is MBTI.
It is not unusual to attempt to teach a concept in terms of a more popular concept in order to sell that concept to a larger audience. All kinds of real world events and concepts get analogized to popular movies such as Star Wars and Lord of the Rings. In the hey day of astrology, the stars were in the sky. Today, those same "stars" are in Hollywood.
Astrology is not a religion and, what we now call Greek Mythology, has long been dead as a religion. So, the question of whether or not you can be compatible with someone who believes in astrology requires further investigation.
The shortage of RoR developers after years of buzz and hype is interesting. I ran across this phenomenon last year and blogged about it.
There's an old quote that goes something like this. Give a man a fish; you have fed him for today. Teach a man to fish; and you have fed him for a lifetime. Computer science is a lot like that fish. If all you learn in school is how to use the current crop of Microsoft developer tools, then the shelf life of your degree will be about five years. However, if you learn the fundamental basics of computer science, then you will have developed the cognitive framework in your mind for easily, almost effortlessly, learning the long list of new programming languages and tools that you will inevitably encounter in your career. That is why universities should focus on the basics and not on the toolset du jour in the workplace.
There's another reason why universities should avoid Microsoft developer tools. Those tools are focused on productivity and not on learning. So, there are all these code wizards that generate tons of boilerplate for you. This may jump start your project but you end up not really developing any understanding of what the wizard generates for you. The typical OSS approach is to avoid wizards and put the productivity boosting features in the software architecture itself.
I used to believe this until I started the web2newsportal project whose client component is a pure AJAX web app. The prototype javascript library and getElementsByTagName does a lot to remove the clunkiness of XML. Also, I am uncomfortable with the script injection vulnerabilities of JSON.
This is not a technology problem, it is a symptom of the stress that this company is experiencing. Large reply-to chains are a CYA strategy. People tend to use this strategy when they are feeling threatened about their employment status.
Seek out the root cause of this stress. Eliminate or mitigate that cause and the email etiquette problems will go away all by themselves.
I hope you're right.
I'm surprised that the companion web site for the book hasn't been posted here yet. It's the catalog that will be of most interest.
Command and Control has to be in-house; however, project oriented duties can most certainly be out-sourced on a case-by-case basis.
Why does CnC have to be in-house? The short answer is conflict of interest. A consultant or employee of an out-sourcing company represents the business interests of his or her company and not yours.
Why should project oriented duties be considered for out-sourcing on a case-by-case basis? Some duties already dovetail nicely with the company's core competency. In which case, you would have lower TCO and shorter ROI by going in-house. Otherwise, you should submit a RFP and pick the vendor whose responses, mediated through the filter of in-house expertise, indicate the lowest TCO and shortest ROI.
Also, consider reading Don't Make Me Think by Steve Krug.
Three of those four vendors have published their own AJAX libraries for outside consumption. This accelerates adoption which is important from the standpoint of going mainstream.
...can't speak to Silverlight...design theory of ajax combined with a good JS api...makes it a much more maintainable and IMHO a nice way to build interactive web apps.I have not used silverlight either. Those whom I have spoken with about it are jazzed about it because you don't have to use java script as the programming language. IMHO, there are serious problems with java script. Not that there's really a problem with the language itself. Rather, the problems show up in how the code engines are implemented. I have gone into more detail about this here. Good programmers can live with these shortcomings either by rendering most of the GUI via HTML and using java script only lightly (i.e. validating event handlers) or by using good libraries and debuggers.
I claim first serious post.
Most of these questions appear to me to be either leading questions, whose intent is to foment desire in the questioners product(s) and/or service(s), or marketing questions.
Some of the questions are legit, however. For example, those questions concerning security, performance, unit testing, and analytics.
With regards to the question about which framework to choose, I have posted my favorites here.
To me, the term scripting has nothing to do with the level of abstraction. Rather, it is more about whether or not the source is directly interpreted or compiled into an intermediate form. Having said that, I must admit that it would be awfully silly to create a low level language that is interpreted.
From most of the languages that he lists, it looks to me that what he is really talking about are Dynamic Scripting Languages. Scripting languages that are also dynamic provide a lot of flexibility and can genuinely be categorized as different from static languages in an interesting way. I have blogged on this recently as part of a larger article on OSS.
Plone is great if it is a good fit between the requirements and developing custom document types within a CMS framework. The architecture is highly layered. The low level way of developing under plone has a non-trivial learning curve to it. The high level way is to use what is known as plone archetypes which makes it really easy to create custom document types. The skinning of the custom types becomes very easy using Zope's METAL technology which is a very cool page templating system.
I have discussed plone previously here and here.
This is a good list. Allow me to weigh in with a few more of my own.
Not to split hairs but, technically speaking, the major browser implementations of GET and POST are not broken. There is nothing in the spec about overlaying the response from either into any arbitrary part of a DOM tree specified by an XPATH or XQUERY expression.
I think that it would be easier from a developer perspective here in 2007 to just code some java script than it would be to change something as fundamental as RFC 2616 and to rewrite every web browser in existence to accommodate that.
You have proposed that the web browser eliminates the running of any script or program client side. Barring obnoxious advertising, the reason why java script (or, more precisely, AJAX) is compelling is that the screen repaint from a traditional HTTP GET or POST reloads the entire screen. This "flash" is disorienting to the end user and can break up their natural flow.
I have recently blogged on this subject in my Top OSS for Coders article.
I use GSview. Is that vulnerable to this backdoor exploit? I suspect that it is not because I don't believe that this PDF viewer does anything special with URLs.
Right. And what about capturing mechanisms? For example if you had to take the value from one part of the XML...
That's where notation systems such as http://www.bpmn.org/ or http://www.oasis-open.org/committees/wsbpel might be useful.
Let me see if I am getting this straight. You wrote a java script app that makes 1500 XHRs and keeps appending data to the end of the page and you are complaining about how FF is handling that. Is that your claim more or less? Here is my reaction.
This is just a guess but I would say that OO has about 85% of what MSO has. This is not really a problem because us mere mortals use only about 50% of what MSO has anyway.
As far as the retraining issue is concerned, I don't see that as a big barrier either. There is so much difference between versions of MSO, that users who need to be trained on office productivity software, will most likely need to be retrained on each version of MSO anyway. If you have to incur the costs of retraining every three years no matter what, then what difference does it make whether or not you are retraining on MSO or OO?
Although it is true that there is no end user experience of selecting a world, my guess is that it is still a shard based architecture based on location within the world. I base that guess on the observation that object rendering and latency seems to be dependent on the number of people and objects in an area. A densely crowded area has much more lag then a sparely populated area. It is not dependent, however, on how many users are currently logged in to the world.
It seems to me that SL is multi-shard but you don't explicitly select the shard. Moving from one part of the world to another may move you to a different shard.