I agree there are better ways to do things than NaCl, but Yoshiki was able to get Squeak running in it, and that was a milestone benchmark that points the way for better systems than Squeak.
Cheers, Alan ________________________________ From: Jakob Praher <[email protected]> To: [email protected] Sent: Mon, July 25, 2011 1:59:03 PM Subject: Re: [fonc] Alan Kay talk at HPI in Potsdam On 07/25/2011 09:35 PM, Bert Freudenberg wrote: > I did ask in that thread about exposing the CPU, a la NativeClient. (It's a >usenet group so you can post without subscribing, nice) > > Short answer is that they don't see a need for it. I somehow have mixed feelings about NaCL. I think that safe execution of native code is a great achievement. Yet the current implementation somehow still feels a bit like safer reincarnation of the ActiveX technology. It defines a kind of abstract toolkit (like ActiveX used WIN32 API) that enables you to interact with the user in a definite way (graphics, audio, events). I think it fails to achieve a common low level representation of data that can be safely used to compose powerful applications. From this point of view I think that e.g. message passing (in a pepsi/cola way) with capabilities based security is much more interesting concept to hide powerful computation than having to rely on a IPC (the pepper interface in NaCl). Also people should address introspectabilty and debuggability right at the core - e.g. enforce symbols for debugging into the applications. I think introspecabilty (the right to "View Source") is one of the biggest improvements of Javascript compared to e.g. Java. Cheers, Jakob _______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
