5 ms·

I don't see what benefits this has C doesn't... maybe someone will see them. Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.

by m0skit0 14y ago

andreasvc 14y ago
Does C run in Firefox? No? Well there you have your benefit.
- billwashere 14y ago
  How about emscripten then? https://github.com/kripken/emscripten https://github.com/kripken/emscripten *Not that I would.
  - andreasvc 14y ago
    Well that seems to be a competitor. If you'd asked me the benefit of emscripten over this I wouldn't have known, but the question was about C.
    - mbebenita 14y ago
      The benefit over Emscripten is that LLJS makes it easier to mix JS and C-like code and skip the C/C++ tool chain. Of course, the drawback is that you miss out on all the LLVM optimizations.
- agentultra 14y ago
  http://www.cs.cornell.edu/home/ulfar/cuba/paper/ http://www.cs.cornell.edu/home/ulfar/cuba/paper/ Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way. Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?
  - mbetter 14y ago
    You get on that, let me know how it turns out.
  - andreasvc 14y ago
    An important reason is security. The security of any web language is of vital importance, for obvious reasons. When you go low level or introduce umpteen different languages, maintaining the same level of security becomes increasingly challenging. But I agree with you that JS is an unfortunate language to be stuck with (although many people appear to be content with it). I especially dislike that it's weakly typed. Isn't Google's NativeClient something like what you're suggesting though?
    - agentultra 14y ago
      I'm not suggesting anything, the paper I linked just described one such method for executed untrusted binary code through the browser. At a cursory glance it looks like NativeClient is built on a sandbox and doesn't allow arbitrary binary applications to run natively on the OS. It doesn't allow system calls and looks like some sort of run-time manages memory on behalf of the application. If you're at all interested, it cannot hurt to read the paper I linked to. It was written in 1997 and requires a little bit of historical forgiveness but the ideas are rather quite interesting.
  - LnxPrgr3 14y ago
    Google's already on it: https://developers.google.com/native-client/ https://developers.google.com/native-client/ Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.
pav3l 14y ago
Javascript can run in the browser, distributed computing. http://hackaday.com/2009/03/03/distributed-computing-in-javascript/ http://hackaday.com/2009/03/03/distributed-computing-in-java...

I don't see what benefits this has C doesn't... maybe someone will see them. Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.

by m0skit0 14y ago

I don't see what benefits this has C doesn't... maybe someone will see them. Anyway cool idea and runs flawlessly in Firefox 15.0.1@Ubuntu 12.04.

andreasvc 14y ago

Does C run in Firefox? No? Well there you have your benefit.

billwashere 14y ago
How about emscripten then? https://github.com/kripken/emscripten https://github.com/kripken/emscripten *Not that I would.
- andreasvc 14y ago
  Well that seems to be a competitor. If you'd asked me the benefit of emscripten over this I wouldn't have known, but the question was about C.
  - mbebenita 14y ago
    The benefit over Emscripten is that LLJS makes it easier to mix JS and C-like code and skip the C/C++ tool chain. Of course, the drawback is that you miss out on all the LLVM optimizations.
agentultra 14y ago
http://www.cs.cornell.edu/home/ulfar/cuba/paper/ http://www.cs.cornell.edu/home/ulfar/cuba/paper/ Any language could. Javascript's ubiquity is just an accident of history. Nobody planned for it to be this way. It's not even the best way. Why not a C applet in the browser with access to native hardware? Let the OS handle access to memory and system call interception. Why not CL? Or Python? Or anything else? Why do we have to let JS continue to be the de facto language and tack on all of these monstrosities upon it?
- mbetter 14y ago
  You get on that, let me know how it turns out.
- andreasvc 14y ago
  An important reason is security. The security of any web language is of vital importance, for obvious reasons. When you go low level or introduce umpteen different languages, maintaining the same level of security becomes increasingly challenging. But I agree with you that JS is an unfortunate language to be stuck with (although many people appear to be content with it). I especially dislike that it's weakly typed. Isn't Google's NativeClient something like what you're suggesting though?
  - agentultra 14y ago
    I'm not suggesting anything, the paper I linked just described one such method for executed untrusted binary code through the browser. At a cursory glance it looks like NativeClient is built on a sandbox and doesn't allow arbitrary binary applications to run natively on the OS. It doesn't allow system calls and looks like some sort of run-time manages memory on behalf of the application. If you're at all interested, it cannot hurt to read the paper I linked to. It was written in 1997 and requires a little bit of historical forgiveness but the ideas are rather quite interesting.
- LnxPrgr3 14y ago
  Google's already on it: https://developers.google.com/native-client/ https://developers.google.com/native-client/ Some part of this seems unsafe intuitively, but then I'm reminded sandboxed interpreted languages don't have the best security track record either.

pav3l 14y ago

Javascript can run in the browser, distributed computing. http://hackaday.com/2009/03/03/distributed-computing-in-javascript/ http://hackaday.com/2009/03/03/distributed-computing-in-java...