Live data from Hacker News

Lua to Javascript translator

github.com

21–30 of 30 posts

Re: Lua to Javascript translator

#21
post #14

Very cool! Ignoring the relative strengths/weaknesses of the languages themselves , JavaScript's killer feature is that it is ubiquitous in web browsers and Lua's killer feature is that it has an extremely small and easy-to-embed implementation. With a project like this you could write code in Lua and get the best of both worlds. When it comes to actually comparing the languages though, Lua is the language that you'd…

Don't you lose the compact advantage of Lua in the conversion?

Sure, but it could allow a single code-base to be portable to both to the tiny Lua VM and the web.

Re: Lua to Javascript translator

#22
post #8

This is a cool project, but sadly it's not a complete Lua. It's missing two of Lua's most powerful features: A lot of the metatable functionality just won't work: http://www.lua.org/manual/5.1/manual.html#2.8 Second, it's missing co-routines. Which is a way to suspend the execution of a piece of code. These features aren't possible in a compiler that simply translates from Lua to JS because JS doesn't have the abilit…

Looks like the only metatable stuff they don't dupport is weak references and garbage collection hooks (finalizers/destructors) Other then that t looks like the support most of the other stuff since table access and things like tha through intermediate functions such as lua_tableget and so on.

Re: Lua to Javascript translator

#23
post #7

Javascript is an usable language, just need an open mind to learn it. Javascript is a simple language. Compile(translate) other language seems good. But complicated things.

Lua is simpler though

Re: Lua to Javascript translator

#24
post #15
post #11

Earlier quoted context omitted.

I have half-a-mind to hack LuaJIT into Webkit I've been thinking for a while that Lua and especially LuaJIT are so good that there might exist a strategy to do an end run around vendors and get LuaJIT into browsers as (initially) a plug-in. It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in.

> I've been thinking for a while that Lua and especially LuaJIT are so good that there might exist a strategy to do an end run around vendors and get LuaJIT into browsers as (initially) a plug-in. It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in. Please don't create yet another plugin. Plugins are bad for…

If the web is so moribund that its health relies on convincing individual hackers not to do things they think would be cool, then the web is doomed. I don't think it is; I think your argument is self-defeating. It makes me want to make a LuaJIT plugin more, not less. LuaJIT is seriously cool.

If it were merely a question of some minor incremental improvement, such as could be obtained by "contribut[ing] to one of the three open source JS engines", then I agree it wouldn't be worth the fragmentation. But then it wouldn't meet the definition of a "killer app" either. Nor would it be likely to gain traction. It would just be a gnat.

What I'm talking about is only interesting if it might be disruptive. I think there's a chance that Lua as both language and implementation is good enough that it might enable things that simply aren't doable (performantly) in other ways. Perhaps I underestimate how many tricks the V8 people have left in their bag. I hope so. But at some point they're going to reach a wall caused by JS's design limitations that simply can't be drilled through. I take the existence of Dart to be a tacit admission of that wall. And what is so amazing about LuaJIT is that it has already proven it does not know that wall.

At the same time Lua is so similar semantically to JS that it is not likely to mess with the things that made JS great, so integrating Lua into the web would arguably be a conservative design choice – more conservative, perhaps, than many proposals to "fix" JS by making it more static and proper-like.

Re: Lua to Javascript translator

#25
post #24
post #15

Earlier quoted context omitted.

> I've been thinking for a while that Lua and especially LuaJIT are so good that there might exist a strategy to do an end run around vendors and get LuaJIT into browsers as (initially) a plug-in. It's possible that there's a killer app waiting to be written that could run well in LuaJIT (but not JS) and that this could drive installation of such a plug-in. Please don't create yet another plugin. Plugins are bad for…

If the web is so moribund that its health relies on convincing individual hackers not to do things they think would be cool, then the web is doomed. I don't think it is; I think your argument is self-defeating. It makes me want to make a LuaJIT plugin more, not less. LuaJIT is seriously cool. If it were merely a question of some minor incremental improvement, such as could be obtained by "contribut[ing] to one of the…

> If the web is so moribund that its health relies on convincing individual hackers not to do things they think would be cool, then the web is doomed. I don't think it is; I think your argument is self-defeating. It makes me want to make a LuaJIT plugin more, not less. LuaJIT is seriously cool.

Well, hack all you want (not like you need anyone's permission ;), my concerns were not with that part, but with

> a strategy to do an end run around vendors [..] drive installation of such a [LuaJIT] plug-in

Hack it up if you want. But if you make a serious effort to drive adoption of a new plugin - that I have a problem with.

> Perhaps I underestimate how many tricks the V8 people have left in their bag. I hope so. But at some point they're going to reach a wall caused by JS's design limitations that simply can't be drilled through. I take the existence of Dart to be a tacit admission of that wall.

I also take Google's focus on Dart as partial admission of not being able to get V8 performance to where they want. But (luckily for the web), V8 is not the only game in town.

Competitors to V8 have introduced new approaches that show a lot of promise - background compilation in IE, full-program type inference in Firefox - with many more ideas remaining.

So I really doubt there will be a LuaJIT killer app. Lua might be faster on some benchmarks now, but it likely loses on others (like on any language comparison), and in any case the difference will become smaller over time.

Re: Lua to Javascript translator

#26
post #3

Lua is a better language than Javascript in every possible way. I have half-a-mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this point. The biggest shame in all of web development is the "type" attribute on the HTML "script" tag...

Lua won't complain about this:

    function example(x)
        print(X)
    end
Because of the subtle bugs that can arise from Lua's undefined variable behavior, I prefer Squirrel:

    local a = {}
    a.x = 5  // Throws an exception
    a.x 
Squirrel also supports JSON syntax for table creation.

Re: Lua to Javascript translator

#27
post #3

Lua is a better language than Javascript in every possible way. I have half-a-mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this point. The biggest shame in all of web development is the "type" attribute on the HTML "script" tag...

> Lua is a better language than Javascript in every possible way.

How about unicode and regexp support?

Re: Lua to Javascript translator

#28
post #27
post #3

Lua is a better language than Javascript in every possible way. I have half-a-mind to hack LuaJIT into Webkit, but I'm afraid that it may be futile at this point. The biggest shame in all of web development is the "type" attribute on the HTML "script" tag...

> Lua is a better language than Javascript in every possible way. How about unicode and regexp support?

So regexp is easy: the Lua authors assert that their irregular-regular expressions (match library) cover the 80% use case for regular expressions while maintaining excellent performance and avoiding the hell that regexps can all too easily descend into. Based on some of the regexps that I've come across in my time...I'm inclined to agree with their decision.

As for unicode, I also rather like their approach: we give you the low level tools, and you are free to implement whatever sort of encoding support you like on top of that. I used Ruby 1.8 when a string was just a bucket-o-bytes, and now I use Ruby 1.9 where every string MUST HAVE AN ENCODING OR ELSE! Based on my experience with both, I'd much rather not have encoding forced on me. That said, it would be nice to see a unicode implementation "blessed" by the core team (but the seem loath to "bless" any libraries).

Re: Lua to Javascript translator

#29
post #20
post #10

Hum, i think everyone love javascript, but no one wants to actually write some ...

(thats what i can deduct from all these lib to convert whatever into js)

Javascript has the benefit of being able to easily run natively on the web. Lua is more complex to get running in a browser, as other languages are as well.

Javascript has the disadvantage in that some people know and love and feel more comfortable in other languages. If you can convert from a language you love to a language that makes it easy to get into a browser... that's the dream.

Re: Lua to Javascript translator

#30
post #20

Earlier quoted context omitted.

(thats what i can deduct from all these lib to convert whatever into js)

Javascript has the benefit of being able to easily run natively on the web. Lua is more complex to get running in a browser, as other languages are as well. Javascript has the disadvantage in that some people know and love and feel more comfortable in other languages. If you can convert from a language you love to a language that makes it easy to get into a browser... that's the dream.

Yup, that's my case, i miss the easy workflow of other languages with "more feature". I miss native namespace and packaging, class, a code completion that works... etc
Post reply on HN