16 ms·

I don't see the connection between Lisp machines and JavaScript. JavaScript (in the browser at least) is a heavy-weight C++ system utilising huge amounts of lib

I don't see the connection between Lisp machines and JavaScript. JavaScript (in the browser at least) is a heavy-weight C++ system utilising huge amounts of library and operating system code with some weak scripting capabilities a the bottom. What relation does that have to Lisp machines or Smalltalk type environments where everything is built in a simple an transparent manner?

jf 15y ago
You're right, it's a weak connection right now. I could be wrong, but I'm seeing JavaScript getting pushed "down" the stack. People are doing things like implementing the DOM in pure JavaScript. I'm also very interested in seeing what people are doing with Emscripten, ClojureScript, swank-js, and the like. Yes, we don't have a Lisp or Smalltalk like environment for JavaScript. Not yet. Given how widely supported JavaScript is though, I could see us getting there organically? Not sure.
- lispm 15y ago
  http://en.wikipedia.org/wiki/Lively_Kernel http://en.wikipedia.org/wiki/Lively_Kernel http://lively-kernel.org/ http://lively-kernel.org/
  - _exec 15y ago
    lispm, I've tried looking up the link you posted a year or so ago to a gallery of Genera software screenshots, but it doesn't seem to be working (lispm.dyndns.org). Have you moved the gallery somewhere else? Please let me know, I'm very interested in seeing how they look!
- javascriptlol 15y ago
  Given that Mozilla aren't willing to redesign their browser to eliminate the recurring flaws, I find it implausible that they're going to go for a balls-out JavaScript-all-the-way-down approach. The way it's going now is more C++ code to do specialised tasks with a bit of scripting on the front. Is stuff like Emscripten getting us closer to a half-way decent design? It seems like this is all just enabling more complexity. Now we'll have C code compiled to JavaScript compiled to machine code. I like Embscripten and so forth for hack value, but this is a terrible way to build systems. I mean, people want sandboxed code in the browser, so why not make the whole browser sandboxed? Because nobody cares enough to put the effort in, I guess. Chrome is the only browser going along these lines and Mozilla is doing its best to hose down that effort because it just might allow people to program for a simple portable VM instead of all this application-parading-as-a-platform web standards stuff.
  - bzbarsky 15y ago
    > Given that Mozilla aren't willing to redesign their browser > to eliminate the recurring flaws http://www.2ality.com/2012/02/servo.html http://www.2ality.com/2012/02/servo.html is worth a read. > Chrome is the only browser going along these lines Chrome is using a C++ core with no plans to stop doing that that I know of....
    - javascriptlol 15y ago
      I wasn't clear. I wasn't meaning to suggest that Chrome were going to move away from C++. But they are trying to sandbox using NaCl and other mechanisms. I was aware of the Rust effort, but not that they were going to implement more of the DOM in JavaScript (thanks!). Maybe there will be more security-by-design. I also think JavaScript is a bad basis for a platform in any case, since it requires loads of complexity to be fast. Why not just a simple typed language or VM? I have read some JS JIT papers and they have found plenty of code generation bugs (more security holes).
      - bzbarsky 15y ago
        I don't think Chrome is trying to sandbox their own code using NaCl, so much; they're just trying to sandbox "arbitrary executable" code.... which is sandboxed automatically if it's JS running inside a JS VM instead of a random binary blob. For the rest, one of the main points of Rust and servo is to have better security-by-design. Whether the DOM ends up implemented in JS or in Rust is still up in the air at this point, but either one would be much better than C++ from a security perspective. As for JavaScript, it's what we have due to happenstance, but displacing it involves either a huge amount more complexity in web browsers (to support JavaScript _and_ another language both touching the same objects and whatnot without memory leaks) or just dropping JS entirely and implementing some other language (not exactly likely to succeed). Maybe someone will create a VM that can run both JS and something else well. Maybe. It's not all that simple to do.
        javascriptlol 15y ago

jf 15y ago

You're right, it's a weak connection right now. I could be wrong, but I'm seeing JavaScript getting pushed "down" the stack. People are doing things like implementing the DOM in pure JavaScript. I'm also very interested in seeing what people are doing with Emscripten, ClojureScript, swank-js, and the like. Yes, we don't have a Lisp or Smalltalk like environment for JavaScript. Not yet. Given how widely supported JavaScript is though, I could see us getting there organically? Not sure.

lispm 15y ago
http://en.wikipedia.org/wiki/Lively_Kernel http://en.wikipedia.org/wiki/Lively_Kernel http://lively-kernel.org/ http://lively-kernel.org/
- _exec 15y ago
  lispm, I've tried looking up the link you posted a year or so ago to a gallery of Genera software screenshots, but it doesn't seem to be working (lispm.dyndns.org). Have you moved the gallery somewhere else? Please let me know, I'm very interested in seeing how they look!
javascriptlol 15y ago
Given that Mozilla aren't willing to redesign their browser to eliminate the recurring flaws, I find it implausible that they're going to go for a balls-out JavaScript-all-the-way-down approach. The way it's going now is more C++ code to do specialised tasks with a bit of scripting on the front. Is stuff like Emscripten getting us closer to a half-way decent design? It seems like this is all just enabling more complexity. Now we'll have C code compiled to JavaScript compiled to machine code. I like Embscripten and so forth for hack value, but this is a terrible way to build systems. I mean, people want sandboxed code in the browser, so why not make the whole browser sandboxed? Because nobody cares enough to put the effort in, I guess. Chrome is the only browser going along these lines and Mozilla is doing its best to hose down that effort because it just might allow people to program for a simple portable VM instead of all this application-parading-as-a-platform web standards stuff.
- bzbarsky 15y ago
  > Given that Mozilla aren't willing to redesign their browser > to eliminate the recurring flaws http://www.2ality.com/2012/02/servo.html http://www.2ality.com/2012/02/servo.html is worth a read. > Chrome is the only browser going along these lines Chrome is using a C++ core with no plans to stop doing that that I know of....
  - javascriptlol 15y ago
    I wasn't clear. I wasn't meaning to suggest that Chrome were going to move away from C++. But they are trying to sandbox using NaCl and other mechanisms. I was aware of the Rust effort, but not that they were going to implement more of the DOM in JavaScript (thanks!). Maybe there will be more security-by-design. I also think JavaScript is a bad basis for a platform in any case, since it requires loads of complexity to be fast. Why not just a simple typed language or VM? I have read some JS JIT papers and they have found plenty of code generation bugs (more security holes).
    - bzbarsky 15y ago
      I don't think Chrome is trying to sandbox their own code using NaCl, so much; they're just trying to sandbox "arbitrary executable" code.... which is sandboxed automatically if it's JS running inside a JS VM instead of a random binary blob. For the rest, one of the main points of Rust and servo is to have better security-by-design. Whether the DOM ends up implemented in JS or in Rust is still up in the air at this point, but either one would be much better than C++ from a security perspective. As for JavaScript, it's what we have due to happenstance, but displacing it involves either a huge amount more complexity in web browsers (to support JavaScript _and_ another language both touching the same objects and whatnot without memory leaks) or just dropping JS entirely and implementing some other language (not exactly likely to succeed). Maybe someone will create a VM that can run both JS and something else well. Maybe. It's not all that simple to do.
      - javascriptlol 15y ago