Hacker News Reader

Comment by 314 | Hacker News Reader

Nice idea, as python is much easier to write code for than lua so should fit game scripting well.

But, the examples are not the kinds of things that I would care about before trying to put this into a game engine. It needs a different set of examples.

* How hard is it to call into a C function from a hook in the py code?

* How hard is it to wrap / unwrap values from their py representation to C?

If you want people to embed the interpreter into an engine then show that it is clean/easy to do the embedding, rather than showing that the interpreter can execute code. I would assume that it executes python, but need to know how well it embeds.

View on HN

Here is what I came up with for calling a c function after poking around a little bit:

  #include "pocketpy.h" 
    
  // builtin function that can be called
  PyVar test(VM* vm, const pkpy::Args& args) {
    printf("called!\n");
    return vm->PyStr("hi there");
  }   

  int main(){
    // Create a virtual machine 
    VM* vm = pkpy_new_vm(true);
    vm->bind_builtin_func<1>("test", test);
    
    // Hello world!
    pkpy_vm_exec(vm, "print(test('Hello world!'))");
    
    // Free the resources
    pkpy_delete(vm);
    return 0;
  }

> as python is much easier to write code for than Lua

No, it isn't. And it isn't harder, too. They're just different.

Is assembly harder to write than lua? How about lisp? I mean you must have some kind of rough ranking of language difficulty in your head. Sure, some of it will be cultural, in a world where middle schoolers are taught s expressions and reverse polish notation lisp might be a lot easier. There certainly is some subjectivity involved.

Still, I think it's reasonable to say that python is easier to write code for.

Scripting use is by definition a less demanding type of requirement than being able to write entire apps.

I wrote a fairly complete "C" subset as a scripting language for a programmable regression test tool (self-contained test-cases able to evaluate the test-case responses). To make it more friendly I made it dynamically typed (so no need to declare variables) and also added XMLPath syntax support as a type of built-in l-value since the requests/responses it was dealing with were XML/JSON, and this meant you could access any elements of the test request/response(s) as if they were just variables.

Anyhow, "C" may not be what comes to mind for a scripting language, but targeting a group of developers who knew C/C++, and with these minor language tweaks made it very simple to use. My point is that for this type of application I'm not sure that the choice of language makes a huge difference - choose something your target audience is comfortable with, and extend in DSL fashion to make it tightly integrated.

In my experience I've found it easier to write Python code. The set of basic types is a little larger, and the core builtins cover more of what I need to do. Lua is a bit more fiddly and verbose, which leads to a more difficult development process (in my opinion). Why would you argue that they have the same level of difficulty?

It was pretty hard for me to get used to Lua's 1-based index and everything treated as a table

I think it's easier to mentally map concepts between C and Python than Lua

Lua scripting can be more commonly performed by people without an engineering background, depending on the workplace. Game designers and level artists probably don't have much C experience, so Python's relative proximity to C is a non-factor.

Reply on news.ycombinator.com