Live data from Hacker News

MoonScript, a programmer friendly language that compiles to Lua

moonscript.org

151–160 of 171 posts

Re: MoonScript, a programmer friendly language that compiles to Lua

#151
post #137

Earlier quoted context omitted.

Honestly, it seems like implicit variable declaration is a bad idea. Some minimal keyword to indicate "this is a new variable in this scope" seems necessary for sane scoping. It nicely prevents a class of bugs of "oops I made a typo in that assignment and created a new variable" gets caught.

Indeed. Is "let x = y+y" so bad? I wonder how much of the resistance owes to longer words like "local"/"define", or ugly abbrevs like "mut"/"var".

So what would you use for declaring a variable that won't be assigned to until lower scope? Like a variable that will be assigned inside a try/catch block but needs to outlive it so it's declared before the try?

Just

    let x
? That looks weird. Or we're back to "var". Or throwing another keyword at x?

    let x exist
Also weird. I've often dreamed of a nice lua-like math with syntax aimed at being familiar to a first year college math student, and "let" is an obvious keyword for variable declaration, but unless you go pure functional you need to be able to pre-declare variables.

Re: MoonScript, a programmer friendly language that compiles to Lua

#152
post #151

Earlier quoted context omitted.

Indeed. Is "let x = y+y" so bad? I wonder how much of the resistance owes to longer words like "local"/"define", or ugly abbrevs like "mut"/"var".

So what would you use for declaring a variable that won't be assigned to until lower scope? Like a variable that will be assigned inside a try/catch block but needs to outlive it so it's declared before the try? Just let x ? That looks weird. Or we're back to "var". Or throwing another keyword at x? let x exist Also weird. I've often dreamed of a nice lua-like math with syntax aimed at being familiar to a first year…

I'd make try/catch an expression, not a statement, like in Lisp -- it'd still be "let x = try {...}...". I agree that 'var' for mutable bindings is a reasonable design. In E it's 'def' for immutable and 'var' for mutable, for instance; and you can also write just 'def x' and then 'bind x := 42' further down (with single-assignment semantics). But though that's nice to have, you can do all right without it; if there was just a single form of definition, with lexical scope, I'd still prefer it to Lua or Python's designs -- clearer and less error-prone and still concise.

Re: MoonScript, a programmer friendly language that compiles to Lua

#153

On a related topic, Haxe now compiles to Lua as well : https://haxe.org/blog/hello-lua/ (disclosure : I'm the author of the lua target) Back to moonscript/Lua, I've been super impressed with the YAGNI principals of the language. I was originally drawn to LuaJIT and its raw speed, but there's a lot of great things to say about the language and its community. My goal is to write more Lua for smaller scripting purposes,…

Thank you. The more I use Haxe the more I love it and I have compiled to Luna and it worked flawlessly. Thank you

It makes my day to hear this. Glad it is useful!

Re: MoonScript, a programmer friendly language that compiles to Lua

#154
post #134
post #53

Earlier quoted context omitted.

The reason is that the _ENV feature added in 5.2 would significantly slow down LuaJIT if it were supported. It's possible that Luac and LuaJIT will re-converge when Lua 6.0 is released, but arguments about this between Mike Pall amd Roberto Ierusalimschy have been unproductive so far. Until then, LuaJIT compiles Lua 5.1 with support for a few 5.2 and 5.3 features, particularly goto.

Why would `_ENV` slow down LuaJIT? It only offers a subset of the `setfenv()` functionality of Lua 5.1 that's implemented in LuaJIT...

It uses lexical scoping, so it probably would mess up traces.

Re: MoonScript, a programmer friendly language that compiles to Lua

#155
post #116

Earlier quoted context omitted.

A couple of friends just successfully launched a commercial game on android/ios/steam using love2d, and they're really happy with the results. I couldn't believe it was made with lua, it runs really smooth. http://midipixel.com/warlockstower/

The love2d source code is in C++. I believe Lua interpreter was embedded as a scripting mechanism https://bitbucket.org/rude/love/src

AFAIK, LÖVE integrates LuaJIT.

Re: MoonScript, a programmer friendly language that compiles to Lua

#156

Earlier quoted context omitted.

Not particularly a fan, that analogy is solid. To me, a pig in lipstick seems somewhat more disturbing than one without.

I was riffing on an old expression of putting lipstick on a pig. https://en.wikipedia.org/wiki/Lipstick_on_a_pig

I realize that, but the point of the saying is typically that a pig with lipstick is little or no better than without. My point is that Coffeescript makes JS worse. It just adds an additional layer of complexity when you end up debugging the same old JS traps. The saying still holds up, because a pig wearing lipstick could actually be worse than a plain pig.

Re: MoonScript, a programmer friendly language that compiles to Lua

#157
post #116

Earlier quoted context omitted.

The love2d community is definitely still active, especially on IRC. Some of the nicest folks I've ever spoken to over the internet. I can't recommend the language or its community highly enough.

A couple of friends just successfully launched a commercial game on android/ios/steam using love2d, and they're really happy with the results. I couldn't believe it was made with lua, it runs really smooth. http://midipixel.com/warlockstower/

Why wouldn't it run smooth if it was made with Lua?

Re: MoonScript, a programmer friendly language that compiles to Lua

#158

Earlier quoted context omitted.

I was riffing on an old expression of putting lipstick on a pig. https://en.wikipedia.org/wiki/Lipstick_on_a_pig

I realize that, but the point of the saying is typically that a pig with lipstick is little or no better than without. My point is that Coffeescript makes JS worse . It just adds an additional layer of complexity when you end up debugging the same old JS traps. The saying still holds up, because a pig wearing lipstick could actually be worse than a plain pig.

Ah, well in that case we are in disagreement. I think Coffeescript is a big improvement. It produces JS code that conforms to The Good Parts™ without having to remember to always add that third equals sign or the var keyword to avoid making a global and other such ridiculous bull-ka-ka.

So you end up not debugging the same old JS traps as much because it is a lot harder to write them. (You get to debug shiny new JS traps instead, but there's only so much a good lipstick can do.)

But it's fine if you prefer javascript to coffeescript. Tastes differ. Some people like bull-ka-ka. runs away

Re: MoonScript, a programmer friendly language that compiles to Lua

#159
post #151

Earlier quoted context omitted.

So what would you use for declaring a variable that won't be assigned to until lower scope? Like a variable that will be assigned inside a try/catch block but needs to outlive it so it's declared before the try? Just let x ? That looks weird. Or we're back to "var". Or throwing another keyword at x? let x exist Also weird. I've often dreamed of a nice lua-like math with syntax aimed at being familiar to a first year…

I'd make try/catch an expression, not a statement, like in Lisp -- it'd still be "let x = try {...}...". I agree that 'var' for mutable bindings is a reasonable design. In E it's 'def' for immutable and 'var' for mutable, for instance; and you can also write just 'def x' and then 'bind x := 42' further down (with single-assignment semantics). But though that's nice to have, you can do all right without it; if there w…

I'd use "set" instead of "bind" and be consistent that assignment leverages the vanilla equality operator (since we're already talking about that for "let") but yeah, it sounds like you've been thinking about the same stuff I have.

It sounds like you've been pondering the same problems I have.

In my case it's because I've been working on a rules-engine for scientists and currently we're using SQL for the rule language and some of the syntactic warts of SQL are tripping us up.

I keep meaning to learn enough Racket Scheme to experiment with implementing such a language in macros.

Re: MoonScript, a programmer friendly language that compiles to Lua

#160
post #134

Earlier quoted context omitted.

Why would `_ENV` slow down LuaJIT? It only offers a subset of the `setfenv()` functionality of Lua 5.1 that's implemented in LuaJIT...

It uses lexical scoping, so it probably would mess up traces.

Late reply, but so does setfenv:

    > function foo()return function()return a end end
    > =foo()()
    nil
    > a=5
    > =foo()()
    5
    > setfenv(foo,{a=6})

    > =foo()()
    6
Post reply on HN