It's been a long time since I've done Lua (2005/2006 IIRC?), but I remember Lua's C embedding API being remarkably excellent already.
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.
Yeah, I'm going to have to agree here. Neat language, but I've always found Lua's C integration to already be one of it's strengths(along with a low-overhead VM).
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.
I must have missed something, because when I was doing Lua/C integrations I had to write a C shim layer that managed a stack of variables which were dequeued to then feed into the actual C call I wanted to make from Lua. It was anything but seamless.
It was my experience too. What does the C API do for one? I've always found it rather unhelpful, though relatively straightforward for simple bindings. (I don't like to comment about anything more involved.) But, even once you've got your own wrappers in place for converting Lua userdata objects to pointers to your custom types, and whatever, your average Lua binding still looks like this:
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
(You can write your own system to automate all of this this - rather more straightforward in C++ than in C - but that is hardly evidence that the C API is especially useful.)
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;
}
(It's worth having a scrabble through to see what the luaL stuff is doing internally, because some of it is string-happier than you might like. luaL_checkudata seems particularly rude. But checkinteger and checknumber seem benign enough.)
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:
Wait, what are you people expecting from the C API? Do you not realize literally every other scripting language integration faces this exact design?
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.
Yes, exactly: you have to write little shim functions. I'm pretty sure this was what bdamm was complaining about, and I'm complaining about it too. I took your suggestion to be that there was some way of using the API that avoided 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 ;)
For instance, interfacing with c in factor works like this. You have an internal dsl that allows you to express what the signature of a c function is. It is designed to look like a function declaration in c, but it is actually valid factor. And... that's it! You can now call that function, and some meta programming drives from that pseudo signature all the information to translate values back and forth
Exactly. Anyone who has ever actually done embedded work with Lua knows you can hardly get any closer in terms of "low-level" outside of the C API besides using LuaJIT's ffi.
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.
The front page describes three distinct use cases for Terra.
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.
You can cover literally the first two things with LuaJIT. Point three covers the fact that it can be used as "a stand-alone low-level language." So really, the only "advantage" this software has is that it is a different language. That's not an advantage on its own.
If you're using Lua to not use Lua, you never wanted to use Lua to begin with!
> You can cover literally the first two things with LuaJIT.
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.
I think Terra functions are AOT compiled and have explicit strong types. So it's quite a different thing that LuaJIT. For example, you could use Terra to actually write a JIT.
The snark was overdone ("because pretty", "just no", etc).
"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").
I've given my technical criticism. LuaJIT + it's ffi module by themselves do a better job than this poor excuse for software. They contain more features by themselves such as all of the "positives" Terra claims to provide (which are actually already provided by LuaJIT as well as preserving drop-in replacement potential, not screwing with syntax, and not having to initialize a secondary system alongside the Lua VM itself.)
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.
>I've given my technical criticism. LuaJIT + it's ffi module by themselves do a better job than this poor excuse for software
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.
Ugh, your arguments are insufferable and reek of someone who only has surface understanding. Please go back to submissions and stay out of comments.
> 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?
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.
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.
Let's not get caught up in definitions. I called it snark because it was sarcastically dismissive. We can use a different term if you prefer.
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.
