On 7/25/2011 12:59 PM, David Barbour wrote:
On Mon, Jul 25, 2011 at 9:25 AM, Igor Stasenko <siguc...@gmail.com
<mailto:siguc...@gmail.com>> wrote:
how different our systems would be, if guys who started it 20
years back would think a bit about future?
The guys who spend their time thinking about it lose, just as they
always do. Worse is better wins on the market. Brendan Eich was right
to fear something even worse than his rapidly hacked brainstorm child
- i.e. if it were not JavaScript/EcmaScript, we might be using
proprietary VBScript from Microsoft.
or, that happens...
then later ends up disabled by default as MS can't manage to prevent
computer from being "pwnt" ("owned") by viruses.
later on someone else recreates web-scripting in a more "secure" form
using a 3rd-party browser plugin which gives a semi-programmatic
interface based on XSLT and regexes.
...
Do you remember those battles between behemoths trying to place
proprietary technologies in our browsers? I do. 'Embrace and extend'
was a strategy discussed and understood even in grade school. I'm a
bit curious whether Google will be facing an EOLAS patent suit for
NaCl, or whether that privilege will go to whomever uses NaCl and
WebSockets to connect browsers together.
although NaCl is an interesting idea, the fact that it was not
originally designed to be binary-compatible between targets is a drawback.
it is sad though that there is no really "good" compromise between
higher level VMs (Flash, .NET, JVM, ...) and sandboxed native code.
and, no one was like: "hell, why don't we just write a VM that allows us
to run sandboxed C and C++ apps in a browser" (probably with some added
metadata and a validation system).
an example would be, say, if the VM didn't allow accessing external
memory via forged pointers, ...
It is interesting to see JS evolve in non-backwards-compatible ways to
help eliminate some of the poisons of its original design -
eliminating the global namespace, dropping callee/caller/arguments,
development of a true module system that prevents name shadowing and
allows effective caching, and so on. Mark Miller, who has performed
significant work on object capability security, has also started to
shape JavaScript to make it into a moderately sane programming
language... something that could be used as a more effective
compilation target for other languages.
fair enough.
too bad there is no standardized bytecode or anything though, but then I
guess it would at this point be more like browser-integrated Flash or
something, as well as be potentially more subject to awkward versioning
issues, or the bytecode ends up being lame/inflexible/awkward/...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
