Hacker News Reader

Comment by ainar-g | Hacker News Reader

>null

>dynamic typing

>naked if-else bodies

I'm sorry, but I just don't see how this improves on anything. How will GravLang make me a better, more productive programmer? How will it make my programs more robust?

Don't get me wrong, as a hobby project it's fine, but as a "real" language it doesn't have any selling points to me.

View on HN

It doesn't improve much on e.g. JavaScript or Python. That's not the point. The point is that it's a small fast zero-dependency embeddable language that could be used for e.g. scripting in games or small devices.

Wren is another nice one:

https://github.com/munificent/wren

Don't we have already Lua for that? It even has a state-of-the-art JIT compiler.

I am all in for competition, but I can't see how both of these languages could improve over Lua.

Although LuaJIT is crazy fast, it can't be used on iOS, so we first need to compare this with the unJITted version of Lua.

Lua is pretty simple and elegant, but has its woes on being too flexible and wonky (especially with nil and global variables). It also doesn't support OOP syntax directly, so everyone started to create their own wonky class system, which broke easily because of Lua's wonkiness. Gravity seems like a good embedding language packaging a nice OOP syntax with a lot of syntactic sugar (such as properties and access specifiers), so I think some UI/game developers would choose this over Lua.

>it can't be used on iOS

LuaJIT interpreter which is _faster_ can be used on iOS. So you would use an immature language everywhere because you can't use the fastest implementation on one platform (iOS), when infact, the LuaJIT interpreter is the fastest interpreter of any dynamic language on all platforms.

Wonkiness is not a substantive claim. How do class systems break because of it?

Magic methods are wonky. Things that get called, although they don't exist, have to traverse an arbitrary system to determine an implementation (may or may not exist). Now add that you can determine that system of traversal, at runtime. Now add arbitrary constraints like 42 local vars per scope, singular inefficient table, no switch (but currying is ok, certainly one of these is more confusing than the other in every CS class) ultimately forcing some wonkiness in every project. It's truly a strange confluence of features leading to an even dumber javascript. I use Lua a lot.

Different strokes I guess.

I consider Lua's type system almost mathematical in its elegance. For my taste, Lua is the penultimate dynamic language, held back only by the unforgivable Wirth-style indexing from 1.

The one place where I simply must correct you is in calling tables inefficient. LuaJIT's implementation, as interpreted, is demonstrably among the fastest general-purpose container classes in widespread use.

Of course it can be used on iOS, there are commercial applications that do exactly that. You can turn off the JIT and you're left with probably the fastest interpreter for a dynamic language that currently exists.

LuaJIT is state-of-the-art even without the JIT. A lot of people miss this and go down various rabbit holes only to come up with something that's significantly worse. Personally, given what I just described, I don't see how Gravity compares at all favorably to Lua.

I see your point, although I would probably use something like mruby[1] if I wanted something embeddable and OO.

[1] http://mruby.org/

I've also looked at mruby, but the language seemed quite complex. (It claims to have a Ruby compatible syntax, but also has its strange warts.) It doesn't help that its documentation is rather poor. Also by looking at the issues section I was pretty scared about the bugs that might come up while using this (https://github.com/mruby/mruby/issues). If there was any successful usage of it in game development I would have jumped in, but so far I haven't found any.

Can anything interesting be used on iOS?

There are some nice non-JIT embedded languages such as Angelscript (resembles C++, uses refcounting instead of GC), Squirrel (extension of Lua syntax to support classes and other nice features), and recently Wren (has a nice class system and uses fibers for concurrency).

Does Apple still prohibit any form of downloaded code or scripting or did they finally ease that?

They do if the user can download and execute the code themselves. If the underlying app uses it (e.g. React Native app downloads updated bundle) and user can't touch it then it's okay.

Wren looks interesting. It stands out by the lack of use of setjmp/longjmp for error handling. It's probably side effect of being able to return/suspend fiber from any call stack depth.

Haxe is the leader there, besides swift.

Ok, find me a Lua compiler for my ARM Coretx M4 that can spool up its VM on my chip, run my C functions natively, and takes less than 30k ROM.

There is a difference here where 1/2 people something iphone can run, and the other half want something that would run on a small 32bit.

I want a scripting VM with an FFI. Lua while supposed to be able to do that just isn’t supported by anyone for that purpose.

I think you might be served by elua, embedded lua. I haven't used it myself, but it looks pretty active.

https://github.com/elua/elua

P.s. the cortex m4 is awesome!

eLua is dead though. Shot itself by trying to be a C replacement. If an embedded Lang for embedded micro has system headers to allow you to stay in the embedded Lang - it’s not going anywhere.

>naked if-else bodies

For my own interest, do you have examples of the way other languages do it? I'm interested, and but I'm afraid to google that.

In Go, one has to always write the if-else bodies in curly braces (and, the opening brace should always be on the same line). I think this is great for two reasons. Firstly, it prevents bugs where a very tired programmer needs to add something to the else body, which is written like this:

    else
      foo();

and writes

    else
      foo();
      bar();

which compiles, but doesn't do what you think it does. And I have seen this bug in actual projects.

Secondly, along with gofmt, it prevents style wars.

"In Go, one has to always write the if-else bodies in curly braces (and, the opening brace should always be on the same line)."

If you really want to twist the knife... even Perl 5 gets this right. Even Perl 5 thinks that naked if/else bodies is too crazy and error prone.

'even Perl5'? Perl5 has also 'use strict' which ensure that variables ate declared before usage, a feature that Python doesn't have AFAIK.

That is why I got into the habit, very early on, to always, always enclose blocks in curly braces (or begin-end, depending on the language). If it is ingrained deeply enough, one no longer has to think about it.

But it is nice if the language enforces it. I would even go so far as to claim it is common sense.

It has automagic GC!

Reply on news.ycombinator.com