Hacker News Reader

Comment by pheon | Hacker News Reader

Whats the point of inventing yet another language? Its far better to use existing and proven languages for both a completeness/stood.the.test.of.time point and time it takes a new developer to get up to speed.

Granted I hate C++ with vengeance my poison if choice is C99 + LUA which creates a really powerful lowlevel and high level combo. Using lua to drive it, farming bits out to C, instead of the opposite "scripting language addon" approach. Yeah lua isnt quite as powerfull as lisp but gets pretty close and dosent look like alien space talk to new devs.

View on HN

All languages (except maybe Lisp, COBOL, and FORTRAN) were "yet another language" at some point. This is how innovation happens.

yet with those languages were derived from constructs in math - new is always relative to the context.

Guess it depends on whats the advantage of doing this is? just for fun? or for a serious practical application.

Arguably the languages were not "yet another" in the sense that they were the first application of those concepts to executable code. But your point is well taken: everything has its roots in history.

I would say most reasons for creating new languages -- for fun, for production usage, as a learning experience -- are good.

Nitpick: It's 'Lua', not 'LUA'. (It's Portuguese for "moon", and its predecessor was called 'Sol'.)

While I too prefer C+Lua, Schemes that compiler to C are another option. Chicken Scheme (http://www.call-with-current-continuation.org/) is quite good. Gambit (http://www.iro.umontreal.ca/~gambit/) is also popular, though I have less experience with it.

How is cross-language debugger support? I have looked a few of these options, but in the use case I have in mind, the most likely place for bugs to occur is after crossing between languages multiple times, and not being able to move through the stack is pretty much a show-stopper for moving the high-level logic out of C.

I've not debugged Lua but I am familiar with it's integration into C. I imagine debugging Lua+C is no harder than debugging Matlab+C. You load up the REPL in GDB and set your C breakpoints in GDB and your Lua breakpoints in Lua. After control leaves your C function and goes back into the REPL's guts just hit 'continue' to return to the REPL command line. It's more laborious but still straightforward. The only thing you really can't do is step from the high level language to the low one but you can set the proper breakpoint in GDB right before the call so it's more or less the same.

-----

Edit: sorry not sure if you were talking about Lua or a C-based Scheme, though I imagine it's the same.

I'm not concerned about which language right now, anything with a REPL should be able to work in this way. But the context I'm working in is perhaps a bit trickier. The call stack would normally cross between languages multiple times so just inspecting the stack becomes really clumsy. Since both languages have access to the same data structures, a watchpoint set on the C side can break at a fairly arbitrary point in the interpreter, from which you need to gain control on the other side.

And it's important to be able to attach to a running process and move through the inter-language call stack (e.g. when debugging a deadlock under MPI (distributed-memory)). I haven't found a high-level language that offers this sort of interoperability, but I'd love to hear suggestions.

Lua has a simple API for debugging built in. Because of this, there are several free and a few commercial Lua debuggers available.

I'm not concerned about single-language debugging. Can these debuggers move through a mixed C-Lua stack? My stack might start and end in C, but cross through Lua two or more times. Can I set a watchpoint and get the program to stop wherever the memory is modified, regardless of which language is modifying it (i.e. I'd like to see C source when C touches the memory and Lua source (not interpreter inernals) when Lua code touches it).

Which of the Lua debuggers is your favorite?

There is a commercial Visual Studio plug-in that will do what you want, but I don't recall it's name.

I wrote a Lua remote debugger myself years ago. A nice trick was that you can associate a string with a chunk of code when you load the code. Then you can retrieve that string from the debug API based on the current instruction. I used that to make a table of "chunk name" to "source" as a global variable in LUA. That made it easy for the debugger to retrieve the source regardless of where it came from (file vs interactive console vs who knows what).

I'm more of an assert / test suite / REPL and printf debugging person. I've used gdb when debugging wrappers for C libraries, but my use of the Lua debugging API has mostly been for profiling, code coverage, etc.

GDB works across the language boundary, though. As far as it's concerned, Lua is just a C library.

one thing i really like about lisp/lua presumably erlang and many others. is how trivial it is to send a function down a socket e.g. how functions/bytecode is just a datatype. makes distributed/parallel/async processing so much easier to build.

guessing you cant do this with a compile to C style implementation.

ironic nitpick: It's 'SOL', not 'Sol'.

Ack! You're right!

Reply on news.ycombinator.com