On 25 July 2011 17:01, Dethe Elza <de...@livingcode.org> wrote: > > On 2011-07-25, at 12:47 AM, Alan Kay wrote: > >> For example, some of our next version of Etoys for children could be done in >> JS, but not all -- e.g. the Kedama massively parallel programmable particle >> system made by Yoshiki cannot be implemented to run fast enough in JS. It >> needs something much faster and lower level -- and this something has not >> existed until the Chrome native client (and this only in Chrome which is >> only about 11% penetrated). > > You don't have to wait for Chrome Native Client to have native levels of > performance. Most of the current crop of browsers (i.e. not IE) use tracing > JIT compilers to get close to native performance (in this experiment writing > a CPU emulator in JS, one emulated instruction took approximately 20 native > instructions: > http://weblogs.mozillazine.org/roc/archives/2010/11/implementing_a.html). > Javascript is fast and getting faster, with array operations coming soon and > Web Workers for safe parallelism (purely message-based threads) available now. > > You can play 3D shooters, edit video, synthesize audio, and run Linux on an > emulated CPU in Javascript. I'm not sure what part of that is not fast enough. > > Some of it is cruft and some of it is less than elegant. But having higher > level primitives (like what SVG and Canvas provide) isn't all bad. >
But don't you see a problem: it evolving from simple 'kiddie' scripting language into a full fledged system. It is of course a good direction and i welcome it. But how different our systems would be, if guys who started it 20 years back would think a bit about future? Why all those "emerging" technologies is just reproducing the same which were available for desktop apps for years? Doesn't it rings a bell that it is something fundamentally wrong with this technology? -- Best regards, Igor Stasenko AKA sig. _______________________________________________ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
