3 ms·

Hi Kragen, hope you are well. Yes, the Sun/Netscape Java deal included MILLJ orders from on high, and thereby wrecked any Scheme, HyperTalk, Logo, or Self synt

Hi Kragen, hope you are well. Yes, the Sun/Netscape Java deal included MILLJ orders from on high, and thereby wrecked any Scheme, HyperTalk, Logo, or Self syntax for what became JS. Lua differed a lot (so did Python) back in 1995. Any existing language, ignoring the security probs, would be flash-frozen and (at best) slowly and spasmodically updated by something like the ECMA TC39 TG1 group, a perma-fork from 1995 on.

kragen 2y ago
Well, I'm not dead yet! Looking for work, which is harder since I'm in Argentina. Flash-freezing Lua might not have been so bad; that's basically what every project using Lua does anyway. And by 01995 it was open source. In case anyone is interested, here's a test function from the Lua 2.1 release (February 01995): function savevar (n,v) if v == nil then return end; if type(v) == "number" then print(n.."="..v) return end if type(v) == "string" then print(n.."='"..v.."'") return end if type(v) == "table" then if v.__visited__ ~= nil then print(n .. "=" .. v.__visited__); else print(n.."=@()") v.__visited__ = n; local r,f; r,f = next(v,nil); while r ~= nil do if r ~= "__visited__" then if type(r) == 'string' then savevar(n.."['"..r.."']",f) else savevar(n.."["..r.."]",f) end end r,f = next(v,r) end end end end It wouldn't have been suitable in some other ways. For example, in versions of Lua since 4.0 (released in 02000), most Lua API functions take a lua_State* as their first argument, so that you can have multiple Lua interpreters active in the same process. All earlier versions of Lua stored the interpreter state in static variables, so you could only have one Lua interpreter per process, clearly a nonstarter for the JavaScript use case. The Lua version history https://www.lua.org/versions.html https://www.lua.org/versions.html gives some indication of what a hypothetical Sketnape Inc. would have been missing out on by embedding Lua instead of JavaScript. Did JavaScript have lexical scoping with full (implicit) closures from the beginning? Because I remember being very pleasantly surprised to discover that it did when I tried it in 02000, and Lua didn't get that feature until Lua 5.0 in 02003.

kragen 2y ago

Well, I'm not dead yet! Looking for work, which is harder since I'm in Argentina. Flash-freezing Lua might not have been so bad; that's basically what every project using Lua does anyway. And by 01995 it was open source. In case anyone is interested, here's a test function from the Lua 2.1 release (February 01995): function savevar (n,v) if v == nil then return end; if type(v) == "number" then print(n.."="..v) return end if type(v) == "string" then print(n.."='"..v.."'") return end if type(v) == "table" then if v.__visited__ ~= nil then print(n .. "=" .. v.__visited__); else print(n.."=@()") v.__visited__ = n; local r,f; r,f = next(v,nil); while r ~= nil do if r ~= "__visited__" then if type(r) == 'string' then savevar(n.."['"..r.."']",f) else savevar(n.."["..r.."]",f) end end r,f = next(v,r) end end end end It wouldn't have been suitable in some other ways. For example, in versions of Lua since 4.0 (released in 02000), most Lua API functions take a lua_State* as their first argument, so that you can have multiple Lua interpreters active in the same process. All earlier versions of Lua stored the interpreter state in static variables, so you could only have one Lua interpreter per process, clearly a nonstarter for the JavaScript use case. The Lua version history https://www.lua.org/versions.html https://www.lua.org/versions.html gives some indication of what a hypothetical Sketnape Inc. would have been missing out on by embedding Lua instead of JavaScript. Did JavaScript have lexical scoping with full (implicit) closures from the beginning? Because I remember being very pleasantly surprised to discover that it did when I tried it in 02000, and Lua didn't get that feature until Lua 5.0 in 02003.