A significant factor in the WWW explosion is that it was coming into its own as a an alternative right about the time that the most popular gopher server implementation stopped being free and there were fears that alternative implementations might be subject to attempts to collect money from the same source.
An encumbered web would have reversed the incentive with regard to gopher v. WWW on that score
Of course JavaScript does as well - everything does. But JavaScript has far fewer such assumptions, making it much easier for someone to invent a new CPU and have it run the web well. With NaCl, we might lose that.
NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript, but otherwise might be useful in browser-based applications -- in the long-term, you might want to replace them with JS, but recompiling for NaCl should in many cases be substantially cheaper than reimplementing from scratch; there's probably some performance-related use cases, too, but Google's done a lot on JS performance, and providing high-performance browser features that JS can drive for common uses cases, like 3D graphics, so those will probably be in edge cases.)
So I don't see NaCl, even if ends up being somewhat less easy to port to new architectures than JS, reducing the portability of the things the web is good at now, it just provides options that make the web good at things its not good at now, with potentially somewhat less future portability of those new capacities (though if they become important, resources will naturally get diverted to developing portable solutions, whether its moving PNaCl to new platforms or providing more portable platforms for the use cases that PNaCl enabled.)
Rumor has it MSFT is about to ditch.net developers in favor of HTML 5 + Javascript for "native" applications.
This rumor appears to be based on nothing more than the fact that in showing off a demonstration of new features of Windows 8, they showed off the ability to run HTML5+JS desktop apps (which, unlike the ability to run.NET apps, is a new features of Windows 8) and not the ability to run.NET apps.
Yes, because what I really want to do is use a language that is terrible at string processing! If this were perl, python, or ruby, I might care. I'd rather learn javascript from scratch, than do string processing in C/C++.
If you can run compiled C/C++ code in the browser, you can use pretty much any language you want, since "compiled C/C++ code" includes the compilers and interpreters for most other languages as well. I'm sure there will be implementation tweaks needed to many existing language implementations to get them to work in the NaCl environment, but it'll be a lot lower barrier than reimplementing the compiler to target javascript, or reimplementing the interpreter in JavaScript.
Note that NaCl code is only cross-platform in the sense that it's OS-independent. Being true native code, it's not processor-independent; if you want NaCl modules to run on x86, x64, and ARM, for example, you need to have compiled three separate versions of your NaCl binary, one for each architecture.
For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.
A quick googling finds that PNaCl is scheduled for Jan. 1, 2012 Beta release on Mar. 1, 2012 general release.
Yes, because countries with constitutions never have such a problem, do they?
Actually in terms of suddenly preventing free speech, etc. they don't.
Actually, they often do; the Soviet Union, like the US, had a written constitution (with even broader guarantees of rights)..
Laws -- whether written or unwritten; constitutions, treaties, or regular laws -- don't matter except insofar as people choose to make them matter. Assaults on freedom succeed where the public tolerates them, and fail where the public doesn't; a written constitution may be a factor in either direction (it can serve as a rallying flag for opposition, or serve as a source of apathy as people choose not to take action trusting that since the Constitution exists and in theory protects them, anything that is done must be authorized by it), but is ultimately not the deciding factor.
Who seriously believes that nerds are going to fly in sufficient numbers to the middle east and spend enough money to justify spending a billion and a half dollars on a theme park?
There are nerds -- and, more relevant to the immediate issue, Star Trek fans, which while the two groups overlap aren't the same thing -- in the Middle East. (Including, incidentally, King Abdullah of Jordan.)
Plus, from most of the descriptions I can find in news articles, it seems to be only a mildly Star Trek themed park, and more of a park with some Star Trek themed attraction, as well as local history/cultured themed attractions, etc.
And no, a genuine netbook is not going to be faster than even a 5 year old laptop.
My atom-powered was faster than my 5 year old laptop when I bought i (it also had a higher resolution, though smaller, display.) What distinguished it was no optical drive.
Its pretty much what distinguishes the class. I can create with it (creating doesn't actually take more power than consuming), it doesn't handle heavy multitasking as well as my two-year-older Core2Duo laptop, but "creating" and "heavy multitasking" aren't the same thing, at all.
The US is almost but not quite at record highs on debt as a percentage of GDP. We were at this point previously right at the end of WWII. At the end of WWII we had the Marshall Plan, which allowed us to get out of that debt load.
The US sharply dropped debt:GDP ratio from 1947-1948 on strong economic growth, and the Marshall Plan was introduced in 1948. Even if the argument were revised to credit "post-war US aid to Europe" in general rather than the Marshall Plan in particular, the important thing to keep in mind is that all operated as pretty traditional government stimulus to the US economyu -- the US government provided lots of moneyfor projects, which was spent buying services largely from US business, which produced growth in the US economy. The debt to GDP ratio fell sharply before the debt was significantly reduced.
That mechanism is quite available now, so long as the US doesn't get obsessed with cutting government spending before the economy returns to strong growth.
The math was the reasoning, and it clearly wasn't sound. They invented a post-hoc justification when it was pointed out them that the reasoning wasn't sound, because they were already married to the decision, and that isn't sound either.
the U.S. is hurtling at full speed towards a deficit meltdown, and quibbling over S&P's math doesn't change the fact that the country needs to come to terms with it ASAP.
No, that's not true. Its true that -- largely driven by the Bush tax cuts and the wars in Iraq and Afghanistan -- the Bush years saw the US go from a budget surplus that was on track to pay off the debt in a decade to an unusually large budget deficit, and its true that the housing bubble collapse at the end of the Bush years signalled the beginning of the worst economic situation since the Great Depression and that that has resulted in additional deficit spending (though the Bush tax cut and the wars are still the biggest deficit contributors), but we're not headed for a "deficit meltdown" (which doesn't even make sense) or a (non-manufactured) debt crisis (which does make sense, but isn't currently a problem, either.)
Yes, the Debt:GDP ratio is high -- that's normal in bad economic times, and the worse economic times are the more that tends to be the case -- because GDP growth slows or reverses and public stimulus via deficit spending is used to to address the slowdown in the private sector. The manufactured political crisis over the deficit is an attempt to derail effective response to the immediate economic challenges facing the country, for the benefit of a political party that hopes to use the economic situation against the sitting President.
Well the installation of them at airports allow said places to give the impression that they are doing something regarding those "scary terrorists".
Yes, but that's not the purpose, that's just the mechanism to get the public to accept their tax money being used to provide handouts to the manufacturers.
Over the last few years the most disturbing trend I have seen is programmers that do not have the ability to ship a product. You can talk all the shit you want about architecture, cute technology, methodology but if you don't ship product you don't count.
Shipping code is a management problem, not a programming problem.
I have seen people recite the mantra of "don't optimize prematurely" when I can tell that they think it means to never optimize.
That's often what it means, and not by accident. "Don't optimize prematurely" means don't optimize until there is evidence that you need to optimize, and then only optimize what there is evidence that you need to optimize. In practice, that means (for many components) never optimizing many aspects that could, in theory, be optimized, because optimization never turns out to be the change that offers the most value for the effort.
Don't optimize prematurely ultimately is just a special case of "do the one thing that delivers the most value for the effort, and repeat as needed". Until optimization od the code for any particular characteristic (whether its speed, memory consumption, or something else) is that one thing, doing it is a waste of resources.
Sometimes, one or more of those matters, and sometimes it matters enough that an otherwise correct naive implementation will not suffice, but most of the time, focussing on correctness first and optimizing only where problems become apparent is better than building for speed, size, or other performance aspects first.
And if the problem analysis has been done well, you'll know the times when speed, size, etc. have critical inflexible constraints ahead of time, and know that you have to focus on one or more of those, and which one, and what the boundaries are.
It is important to design things right the first time versus loops and loops of daily optimization that must code is written in today.
Experience has shown that, as nice as that might sound, its really not true most of the time, and in fact most systems face flux in requirements over time such that its better to build small bits that produce correct results, and adapt -- either to optimize, to add new features, or to adjust behavior to meet changing requirements -- rapidly.
Also, there's a very good reason for using Psuedonym...if you are a DJ, for example, people know you by your DJ name. Say, DJ Aphrodite or Kaskade. How ludicrous would it be for Google+ to require DJ Aphrodite to use his real name, when no one knows what that is? How can he invite his friends into his circle to listen to his music of he has to use a real name?
I suspect that the a naming policy that supports using things that aren't your common personal name but serve as brand identities like this will be part of the expansion of Google+ to allow business & organizational profiles, which currently are not supported. Those profiles will, I suspect, be distinguished from regular personal profiles so that people can distinguish real people identified by their common names from entities identified by what amounts to brand identifiers, but I'd be mildly surprised if the accounts didn't otherwise have the full range of options available to individual accounts.
On my HTC Legend I rarely find an intent mime type which is NOT answered by the HTC mail app.
At least the proposed Web Intents use both content types and actions (edit, share, view, etc.); seems to me mail apps would be fairly unrestricted in the content-types they could handle, but very restricted in the actions that they can handle for most content types.
No, it has very little in common with ActiveX; the closest analogy that's been posted on the thread so far is UDDI, but its not very much like that, either.
Sounds like ARexx brought to the Web (an expanded Rexx implementation on the Amiga from the '80s) but standardized.
Its really not all that similar: ARexx was essentially a scripting language integrated into the Amiga platform and to which many Amiga apps provided an interface allowing automation.
Web Intents isn't a new language that sits external to web apps and allows you to automate them.
Discovery is done through one markup tag which advertises that service can handle a particular "intent" (an action), and consumption is done through either a form tag attribute in markup referencing the intent (not the specific service) or a dirt simple javascript API for specifying the intent and the content against which to apply it.
If done right, it would indeed be a very useful thing. However I'm not sure if Google really wants an interface which allows you to select whether you want the service "show the map of New York" requested from the web site to be served by Google Maps or Open Streetview...
Its strange then that they have proposed pretty much exactly that, and delivered the code to implement it in existing browsers.
In any case, the user should be given the option to use a local program instead of a web app.
You can't really do that in a portable JavaScript shim of the type Google has delivered for the current demonstration, but obviously that's a fairly obvious thing to do in a native implementation within a browser (and most browsers already have a framework for defining local content handlers based on MIME types, though this would need to be extended to include actions as a distinguishing factor as well as content type to properly support intents.)
For example, for "edit the image" I might want to use a locally installed Photoshop or Gimp instead of some web app which almost certainly is less powerful, and also likely less familiar (if I have an image editing software installed, most likely it's because I use it). But again, I don't think that's in Google's interest.
Enabling you to more easily integrate your existing desktop apps with web apps (including, inter alia, Google's web apps) is clearly in Google's interest.
Google seems to be proposing a bit of javascript that anyone can add to their website, which will pull my data from any other enabled website I've stored information on?
No, Google is proposing a set of web technologies (markup + JavaScript API) that will allow websites to advertise that they support certain actions, allow you to choose to install those websites as options to handle those actions, and then allow other websites to specify that they want one of those actions performed, at which point you will be presented by your browser with an opportunity to choose which of the sites you've installed as a handler for the action your browser should invoke to handle the action.
They are not proposing a mechanism that will allow websites to pull your data from other websites.
Slashdot Mirror
A significant factor in the WWW explosion is that it was coming into its own as a an alternative right about the time that the most popular gopher server implementation stopped being free and there were fears that alternative implementations might be subject to attempts to collect money from the same source.
An encumbered web would have reversed the incentive with regard to gopher v. WWW on that score
NaCl is not, in my view, a replacement for JavaScript, its a tool for certain purposes for which JavaScript is problematic (one might be re-use of substantial legacy code bases that aren't in JavaScript, but otherwise might be useful in browser-based applications -- in the long-term, you might want to replace them with JS, but recompiling for NaCl should in many cases be substantially cheaper than reimplementing from scratch; there's probably some performance-related use cases, too, but Google's done a lot on JS performance, and providing high-performance browser features that JS can drive for common uses cases, like 3D graphics, so those will probably be in edge cases.)
So I don't see NaCl, even if ends up being somewhat less easy to port to new architectures than JS, reducing the portability of the things the web is good at now, it just provides options that make the web good at things its not good at now, with potentially somewhat less future portability of those new capacities (though if they become important, resources will naturally get diverted to developing portable solutions, whether its moving PNaCl to new platforms or providing more portable platforms for the use cases that PNaCl enabled.)
This rumor appears to be based on nothing more than the fact that in showing off a demonstration of new features of Windows 8, they showed off the ability to run HTML5+JS desktop apps (which, unlike the ability to run .NET apps, is a new features of Windows 8) and not the ability to run .NET apps.
If you can run compiled C/C++ code in the browser, you can use pretty much any language you want, since "compiled C/C++ code" includes the compilers and interpreters for most other languages as well. I'm sure there will be implementation tweaks needed to many existing language implementations to get them to work in the NaCl environment, but it'll be a lot lower barrier than reimplementing the compiler to target javascript, or reimplementing the interpreter in JavaScript.
For now; though with NaCl now in a non-dev version of Chrome (its been in dev versions since 7 or so, I think) that probably means that there is going to be more focus on getting PNaCl (Portable Native Client) ready for public consumption, which will see code deployed on the web as LLVM bitcode and compiled to native code at the client, at which point you'll have real portability.
A quick googling finds that PNaCl is scheduled for Jan. 1, 2012 Beta release on Mar. 1, 2012 general release.
Since when is "PC" defined by having an x86 processor? Were Macs not PCs when they had 680x0 processors, but became PCs when they went with Intel?
Actually, they often do; the Soviet Union, like the US, had a written constitution (with even broader guarantees of rights)..
Laws -- whether written or unwritten; constitutions, treaties, or regular laws -- don't matter except insofar as people choose to make them matter. Assaults on freedom succeed where the public tolerates them, and fail where the public doesn't; a written constitution may be a factor in either direction (it can serve as a rallying flag for opposition, or serve as a source of apathy as people choose not to take action trusting that since the Constitution exists and in theory protects them, anything that is done must be authorized by it), but is ultimately not the deciding factor.
Well, it does, insofar as TFS asserts that this has to do with DNA collection from "criminals" rather than from arrested suspects.
Actually, no, the whole point (and a key factor in it beingstruck down) is that it is not about DNA collection from criminals.
There are nerds -- and, more relevant to the immediate issue, Star Trek fans, which while the two groups overlap aren't the same thing -- in the Middle East. (Including, incidentally, King Abdullah of Jordan.)
Plus, from most of the descriptions I can find in news articles, it seems to be only a mildly Star Trek themed park, and more of a park with some Star Trek themed attraction, as well as local history/cultured themed attractions, etc.
My atom-powered was faster than my 5 year old laptop when I bought i (it also had a higher resolution, though smaller, display.) What distinguished it was no optical drive.
Its pretty much what distinguishes the class. I can create with it (creating doesn't actually take more power than consuming), it doesn't handle heavy multitasking as well as my two-year-older Core2Duo laptop, but "creating" and "heavy multitasking" aren't the same thing, at all.
The US sharply dropped debt:GDP ratio from 1947-1948 on strong economic growth, and the Marshall Plan was introduced in 1948. Even if the argument were revised to credit "post-war US aid to Europe" in general rather than the Marshall Plan in particular, the important thing to keep in mind is that all operated as pretty traditional government stimulus to the US economyu -- the US government provided lots of moneyfor projects, which was spent buying services largely from US business, which produced growth in the US economy. The debt to GDP ratio fell sharply before the debt was significantly reduced.
That mechanism is quite available now, so long as the US doesn't get obsessed with cutting government spending before the economy returns to strong growth.
The math was the reasoning, and it clearly wasn't sound. They invented a post-hoc justification when it was pointed out them that the reasoning wasn't sound, because they were already married to the decision, and that isn't sound either.
No, that's not true. Its true that -- largely driven by the Bush tax cuts and the wars in Iraq and Afghanistan -- the Bush years saw the US go from a budget surplus that was on track to pay off the debt in a decade to an unusually large budget deficit, and its true that the housing bubble collapse at the end of the Bush years signalled the beginning of the worst economic situation since the Great Depression and that that has resulted in additional deficit spending (though the Bush tax cut and the wars are still the biggest deficit contributors), but we're not headed for a "deficit meltdown" (which doesn't even make sense) or a (non-manufactured) debt crisis (which does make sense, but isn't currently a problem, either.)
Yes, the Debt:GDP ratio is high -- that's normal in bad economic times, and the worse economic times are the more that tends to be the case -- because GDP growth slows or reverses and public stimulus via deficit spending is used to to address the slowdown in the private sector. The manufactured political crisis over the deficit is an attempt to derail effective response to the immediate economic challenges facing the country, for the benefit of a political party that hopes to use the economic situation against the sitting President.
Yes, but that's not the purpose, that's just the mechanism to get the public to accept their tax money being used to provide handouts to the manufacturers.
Shipping code is a management problem, not a programming problem.
That's often what it means, and not by accident. "Don't optimize prematurely" means don't optimize until there is evidence that you need to optimize, and then only optimize what there is evidence that you need to optimize. In practice, that means (for many components) never optimizing many aspects that could, in theory, be optimized, because optimization never turns out to be the change that offers the most value for the effort.
Don't optimize prematurely ultimately is just a special case of "do the one thing that delivers the most value for the effort, and repeat as needed". Until optimization od the code for any particular characteristic (whether its speed, memory consumption, or something else) is that one thing, doing it is a waste of resources.
I suspect that the a naming policy that supports using things that aren't your common personal name but serve as brand identities like this will be part of the expansion of Google+ to allow business & organizational profiles, which currently are not supported. Those profiles will, I suspect, be distinguished from regular personal profiles so that people can distinguish real people identified by their common names from entities identified by what amounts to brand identifiers, but I'd be mildly surprised if the accounts didn't otherwise have the full range of options available to individual accounts.
At least the proposed Web Intents use both content types and actions (edit, share, view, etc.); seems to me mail apps would be fairly unrestricted in the content-types they could handle, but very restricted in the actions that they can handle for most content types.
No, it has very little in common with ActiveX; the closest analogy that's been posted on the thread so far is UDDI, but its not very much like that, either.
Its really not all that similar: ARexx was essentially a scripting language integrated into the Amiga platform and to which many Amiga apps provided an interface allowing automation.
Web Intents isn't a new language that sits external to web apps and allows you to automate them.
Discovery is done through one markup tag which advertises that service can handle a particular "intent" (an action), and consumption is done through either a form tag attribute in markup referencing the intent (not the specific service) or a dirt simple javascript API for specifying the intent and the content against which to apply it.
There is no "wrapper" involved.
Its similar to UDDI or WS-Discovery in that it provides a service discovery mechanism.
Its dissimilar to them in that it also includes a JavaScript API for calling a service.
Its even more dissimilar in its lack of complexity.
Compare:
Web Intents
UDDI
WS-Discovery
Its strange then that they have proposed pretty much exactly that, and delivered the code to implement it in existing browsers.
You can't really do that in a portable JavaScript shim of the type Google has delivered for the current demonstration, but obviously that's a fairly obvious thing to do in a native implementation within a browser (and most browsers already have a framework for defining local content handlers based on MIME types, though this would need to be extended to include actions as a distinguishing factor as well as content type to properly support intents.)
Enabling you to more easily integrate your existing desktop apps with web apps (including, inter alia, Google's web apps) is clearly in Google's interest.
No, Google is proposing a set of web technologies (markup + JavaScript API) that will allow websites to advertise that they support certain actions, allow you to choose to install those websites as options to handle those actions, and then allow other websites to specify that they want one of those actions performed, at which point you will be presented by your browser with an opportunity to choose which of the sites you've installed as a handler for the action your browser should invoke to handle the action.
They are not proposing a mechanism that will allow websites to pull your data from other websites.