I just skimmed it. I didn’t see a mention of Juice in it or the references. Wonder if Ralph knew about it. Still the best concept I’ve seen for web programming if applied to just low-level form for distribution. The high-level stuff could be anything that’s more expressive than Oberon.
Note: The Juice page appears gone from original site and Wayback. Another bites the dust. I need to make a list and start firing off emails getting permission to mirror all these things.
So I guess in 2006 it wasn’t obvious that you could write a parser and translator in the browser? Otherwise, it doesn’t seem novel? I remember doing this kind of thing in 2009, pre-node.js, pre-CoffeeScript, inspired by some of Crockford’s code. This seems like it’s CoffeeScript with Oberon syntax.
2006 was also pre-v8, so the speed for the translator quoted at the end is pretty bad. Less than 1 line per millisecond!
As is typically the case, the first “breakthrough” in a space (compiling to JavaScript in this case) is ahead of it’s time. Other ideas follow on (e.g. a JavaScript implementation that doesn’t require a browser) that make old ideas, even if they weren’t known to the new innovator before, obvious. What you are describing seems to be exactly that. Perhaps you had a breakthrough that you could precompile in the browser to a textbox? Perhaps the JavaScript execution environment embedded in the JDK was good enough?
It’s definitely interesting how many people reinvent the same thing around the same time, though because of reasons, one usually comes out ahead (for often non-technical reasons). CoffeeScript gained popularity just a bit later…compiling to a textbox for its demo, for instance.
It’s the one I was wowed by a long time ago. What you think of it in historical context and maybe present day if aiming for rapid compilation to native code w/ memory safety?
Hm I didn’t know about Juice, but apparently I was just talking about the architecture-independent code format on HN with vidarh (“semantic dictionary encoding” ):
I compared it to the architecture of v8 and the JVM – all three architectures are distinct.
I think that this SDE format makes sense from a holistic point of view, if you design the whole system, and control both ends of the network.
But I think plain text is simpler for “evolved” systems. To be concrete, JavaScript wasn’t designed to be quickly JIT-compiled on demand, but Google basically brute-forced it with v8 and everyone else followed.
It’s kind of a variant on “worse is better”. In the original worse-is-better, Gabriel is talking about Unix and how it forces user space to handle EINTR.
Here you could say again the Unix philosophy is to just send plain-text code over the network, and not some binary encoding. It forces everyone to do a bunch of work to parse and compile the code quickly. And there is a lot of duplication – v8, SpiderMonkey, JavaScriptCore, Chakra, etc.
But it works in the end, for some definition of “works”. I would say JS is suboptimal from a systems point of view, while Juice/SDE is more optimal. But perhaps JS is healthier from the evolutionary / economic point of view.
A huge data structure in the middle of your compiler isn’t a nice interface to expose over the network. You might want to completely change the architecture later (which happened with JS), and plain text allows you to do that.
It would be interesting to try to design a system that had the best of both worlds… something that humans can write but that computers can also parse and optimize easily.
“But I think plain text is simpler for “evolved” systems. To be concrete, JavaScript wasn’t designed to be quickly JIT-compiled on demand, but Google basically brute-forced it with v8 and everyone else followed. It’s kind of a variant on “worse is better”. In the original worse-is-better”
Oh I agree with you there. JavaScript definitely won out in a Worse is Better kind of way. It definitely should be the target of web languages aiming for mass adoption (esp quick adoption). I was just looking at alternatives that might have better design in The Correct Thing since.
“It would be interesting to try to design a system that had the best of both worlds… something that humans can write but that computers can also parse and optimize easily.”
Specific implementations of Common LISP and Scheme were in fact very interesting. They solved that problem well. Heck, the Chez Scheme dialect that was recently open-sourced goes back to 8-bit days. Talk about efficiency considerations. Mainly those, Tcl, and REBOL/Red seem simultaneously easy for humans and machines to work with. Not many like that.
I just skimmed it. I didn’t see a mention of Juice in it or the references. Wonder if Ralph knew about it. Still the best concept I’ve seen for web programming if applied to just low-level form for distribution. The high-level stuff could be anything that’s more expressive than Oberon.
Note: The Juice page appears gone from original site and Wayback. Another bites the dust. I need to make a list and start firing off emails getting permission to mirror all these things.
There’s also https://github.com/vladfolts/oberonjs
So I guess in 2006 it wasn’t obvious that you could write a parser and translator in the browser? Otherwise, it doesn’t seem novel? I remember doing this kind of thing in 2009, pre-node.js, pre-CoffeeScript, inspired by some of Crockford’s code. This seems like it’s CoffeeScript with Oberon syntax.
2006 was also pre-v8, so the speed for the translator quoted at the end is pretty bad. Less than 1 line per millisecond!
As is typically the case, the first “breakthrough” in a space (compiling to JavaScript in this case) is ahead of it’s time. Other ideas follow on (e.g. a JavaScript implementation that doesn’t require a browser) that make old ideas, even if they weren’t known to the new innovator before, obvious. What you are describing seems to be exactly that. Perhaps you had a breakthrough that you could precompile in the browser to a textbox? Perhaps the JavaScript execution environment embedded in the JDK was good enough?
It’s definitely interesting how many people reinvent the same thing around the same time, though because of reasons, one usually comes out ahead (for often non-technical reasons). CoffeeScript gained popularity just a bit later…compiling to a textbox for its demo, for instance.
I just found one of my old links to Juice:
http://www.modulaware.com/mdlt69.htm
It’s the one I was wowed by a long time ago. What you think of it in historical context and maybe present day if aiming for rapid compilation to native code w/ memory safety?
Hm I didn’t know about Juice, but apparently I was just talking about the architecture-independent code format on HN with vidarh (“semantic dictionary encoding” ):
https://news.ycombinator.com/item?id=15710134
I compared it to the architecture of v8 and the JVM – all three architectures are distinct.
I think that this SDE format makes sense from a holistic point of view, if you design the whole system, and control both ends of the network.
But I think plain text is simpler for “evolved” systems. To be concrete, JavaScript wasn’t designed to be quickly JIT-compiled on demand, but Google basically brute-forced it with v8 and everyone else followed.
It’s kind of a variant on “worse is better”. In the original worse-is-better, Gabriel is talking about Unix and how it forces user space to handle EINTR.
Here you could say again the Unix philosophy is to just send plain-text code over the network, and not some binary encoding. It forces everyone to do a bunch of work to parse and compile the code quickly. And there is a lot of duplication – v8, SpiderMonkey, JavaScriptCore, Chakra, etc.
But it works in the end, for some definition of “works”. I would say JS is suboptimal from a systems point of view, while Juice/SDE is more optimal. But perhaps JS is healthier from the evolutionary / economic point of view.
A huge data structure in the middle of your compiler isn’t a nice interface to expose over the network. You might want to completely change the architecture later (which happened with JS), and plain text allows you to do that.
It would be interesting to try to design a system that had the best of both worlds… something that humans can write but that computers can also parse and optimize easily.
“But I think plain text is simpler for “evolved” systems. To be concrete, JavaScript wasn’t designed to be quickly JIT-compiled on demand, but Google basically brute-forced it with v8 and everyone else followed. It’s kind of a variant on “worse is better”. In the original worse-is-better”
Oh I agree with you there. JavaScript definitely won out in a Worse is Better kind of way. It definitely should be the target of web languages aiming for mass adoption (esp quick adoption). I was just looking at alternatives that might have better design in The Correct Thing since.
“It would be interesting to try to design a system that had the best of both worlds… something that humans can write but that computers can also parse and optimize easily.”
Specific implementations of Common LISP and Scheme were in fact very interesting. They solved that problem well. Heck, the Chez Scheme dialect that was recently open-sourced goes back to 8-bit days. Talk about efficiency considerations. Mainly those, Tcl, and REBOL/Red seem simultaneously easy for humans and machines to work with. Not many like that.