So this is LuaJIT's ffi with some bastardized syntax that immediately becomes incompatible with any other Lua syntax parser, because "pretty."
Just no.
Just no.
C calling Lua, calling back into C, back and forth across the boundary was absolutely painless. Compared with experiencing that in many other languages, at the time, I was convinced that was as easy as it is. (Plus, the size of the lua runtime made it great for embedded projects, whereas now embedded computing has gotten so much more powerful you can really include almost any language stack if you really want to)
As a result, I'm not positive why I need a C-like layer on top for cases where I probably want to write C.
I still would love to see more applications of Lua, it's a really nice language. On the first commercial project I ever worked on we ran all game logic in a 400kb block on a platform with less than 8mb of system ram. Was impressive stuff.
http://lumail.org/ - Maildir only, which needs to be fixed.
1. Get arguments from stack one by one
2. Call C function with arguments
3. Push result(s) to stack one by one
4. Return number of results
Suppose you have a function in lua, `f(x,y)' that you want to forward to your C function, `int f(int x,double y)'. You need to do something like this:
int lua_f(lua_State *L) {
int x=luaL_checkinteger(L,1);
double y=luaL_checknumber(L,2);
int result=f(x,y);
lua_pushinteger(L,result);
return 1;
}
If you don't use a debugger, and you're certain you'll never need any logging or whatever, and you're sure future you won't mind having to split things all out when they are in the middle of something else and discover they need logging after all, you could do it maybe more like this:
lua_pushinteger(L,f(luaL_checkinteger(L,1),luaL_checknumber(L,2));
return 1;
At the end of the day, you will always need to take values, plug them into a function, and return that value back to to the VM if desired.
Lua, Ruby, V8, you name it, they all do it. Are you expecting to magically pass a function and have some metaprogramming do everything for you? I mean this was certainly possible with LuaBind but then you suddenly take on Boost, and any experienced integrator will realize some systems quickly need more control than this.
There might be no better way of doing it (or maybe there might be - I have no opinion), but that wouldn't in my view automatically make the C API "remarkably excellent", "absolutely painless", nor the sort of thing that you might describe as "as easy as it is" (as were the original claims). It would just make it no more inconvenient than it has to be. Forgive me for not getting overly excited at that ;)
If anything this is actually a high level abstraction on top of LuaJIT's ffi, so this is far from low level. God forbid anyone criticize anything on HN.
While criticism is welcome, it certainly appears that you are missing the uses for Terra. Consider the third case - you can write Terra functions (cleaner syntax than C) and use Lua as a meta-programming language that produce more Terra functions (vastly superior to C macros) which then compile down via LLVM to machine code. Your final code has no Lua pieces.
If you're using Lua to not use Lua, you never wanted to use Lua to begin with!
Not at all. You don't have explicit control over generating machine code in LuaJIT. OTOH all Terra functions - whether dynamically generated or pre-written - will get compiled to machine code via LLVM. So it's explicit, i.e. more work, but more predictable. Arguably Terra code generation will cover more scenarios - consider some code paths may not be JITable at all by LuaJIT (due to NYI) but if you can generate a Terra function, you're guaranteed machine code.
> If you're using Lua to not use Lua, you never wanted to use Lua to begin with!
You're using Lua as a meta-programming language for Terra. If you know Lua, it could be a lot more convenient than using custom or archaic meta-programming languages.
"because "pretty.", for example, implies that the creators of the language are shallow idiots that can't take practical considerations into account.
That's hardly specific technical criticism. And it fails to take into account (even just to refute) the whole business cases/design logic as given by them.
Then you answer to complaints about said snark with "Oh sorry, forgive me for having an opinion. I wouldn't want to upset anyone. I guess that's the nature of upvote aggregates, isn't it, to eliminate diverse opinion.".
Still passive-aggresively confrontational.
Which happens to others, and me too occasionally, and I also have got down-voted for that. But it's hardly a case of "eliminating diverse opinion". It's mostly eliminating mere opinion unsupported by arguments, or presented without consideration to the people doing the hard work ("just no").
What arguments can you make besides saying I'm a big doo doo head? Is it not technical criticism because I didn't write it to your liking? I do think the creator(s) of the language are idiots.
Hey guys! Let's not separate syntax by different file extensions or abstraction! Let's put static and dynamic type in the same file! Great idea. That's snark.
The "LuaJIT + it's ffi module by themselves do a better job" part is the opinion/criticism (even without specifics given). And it would be OK and not lead to down-votes by itself. The "poor excuse for software" that follows it, though, would.
>What arguments can you make besides saying I'm a big doo doo head?
A lot of them.
First of all, LuaJIT is not statically typed. Terra is.
Second, it's not meant to be used instead of Lua/LuaJIT but instead of C. For people not wanting to mess with C, Terra can be used as a high level alternative.
Third, yes, there are others in that space. But by that logic, we should stop designing new languages, because there's something else in any niche anyway.
You seem hellbent of comparing it to using Lua. I don't care for Lua, but I wouldn't mind a new high level C/C++ like language. The fact that it's written in Lua is an irrelevant implementation detail (though it does help it get a good interoperability story with Lua. But even for someone NOT caring for Lua, a high level statically typed language such as Terra can be very interesting.
Especially people who don't give a dead rats arse about ffi and going through the the trouble of extensions in C just to consume them in Lua. With Terra they can still do that IF they want, but they can just write in its own language and get C performance.
Then there's the whole language features and design thing, that Terra does differently to Lua and C and C++, and which might fit some better than others. You haven't made one argument against that.
That you prefer Lua, or that you can do the same things with Lua+ffi are not technical arguments. One could do the same thing in assembler or C too, so?
>I do think the creator(s) of the language are idiots.
That just reflects badly on you though.
> First of all, LuaJIT is not statically typed. Terra is.
Wow, phenomenal analysis there genius.
> Second, it's not meant to be used instead of Lua/LuaJIT but instead of C.
Oh really, because anyone knowledgeable enough in C wouldn't use this, so your argument comes from a perspective of a naive tinkerer who likes shiny tech.
> You seem hellbent of comparing it to using Lua. I don't care for Lua.
Why the fuck are you commenting on this anyway then.
> The fact that it's written in Lua is an irrelevant implementation detail.
I bet you make more submissions to HN then you actually write software. This is so disconnected from reality.
> That just reflects badly on you though.
Your whole counterargument reflects on your naivety. You don't care about technical discussion, you just don't like that I don't like the software. Why waste your energy? Why do you bother talking about software you have literally no background in?
There's nothing wrong with criticizing, but there is something wrong with being snarkily dismissive, which your comment upthread was.
It isn't hard to do the one without the other. Most people on HN, including other commenters in this thread, manage just fine.
By the way that's not snark. That would imply I was being snide, like the first two sentences above, provided for your example. What I called the language was a bastardized version of Lua. There isn't anything subtle about it. What this thread is rife with, though, is ignorance.
I'm getting tired of passive aggressive conversation on HN, and elsewhere. It just promotes bullshit and dismissing others voices if they don't pretty it up for the crowd.
If I said something more like, "Wow, what a wonderful set of features, too bad this breaks syntax highlighting and doesn't support drop-in replacement." Then it might be more palatable, but that's not what I thought, nor how I felt.
Snark varies mostly by commenter, not by topic, which implies that people do it for personal reasons (e.g. how they're feeling, or habit) and also that it's off-topic, even when the point you're trying to make is not, as with your comment above. It has two bad consequences for HN: it degrades the channel by adding noise, and it acidifies the culture, making it hostile to new work and new ideas. Those are the things we care about.
Many HN users, including me, have gone through the process of figuring this out in our own case and learning to mostly edit the snark (or bile, or dimissiveness) out of our comments. Perhaps you would be willing to do this if you realized what HN is trying to optimize for, which is curiosity—not any of the things you've listed here. I wouldn't want to participate in those either.
Once one realizes that snark is optimizing for a personal discharge at the expense of the community and quality of the site, it becomes fair to edit it out of one's comments, for the same reason one doesn't litter.