4 ms·

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

by pheon 17y ago

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.

nex3 17y ago
All languages (except maybe Lisp, COBOL, and FORTRAN) were "yet another language" at some point. This is how innovation happens.
- pheon 17y ago
  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.
  - nex3 17y ago
    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.
silentbicycle 17y ago
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/ http://www.call-with-current-continuation.org/) is quite good. Gambit (http://www.iro.umontreal.ca/~gambit/ http://www.iro.umontreal.ca/~gambit/) is also popular, though I have less experience with it.
- jedbrown 17y ago
  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.
  - chancho 17y ago
    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.
    - jedbrown 17y ago
      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.
    - corysama 17y ago
      Lua has a simple API for debugging built in. Because of this, there are several free and a few commercial Lua debuggers available.

by pheon 17y ago

nex3 17y ago

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

pheon 17y ago
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.
- nex3 17y ago
  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.

silentbicycle 17y ago

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/ http://www.call-with-current-continuation.org/) is quite good. Gambit (http://www.iro.umontreal.ca/~gambit/ http://www.iro.umontreal.ca/~gambit/) is also popular, though I have less experience with it.

jedbrown 17y ago
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.
- chancho 17y ago
  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.
  - jedbrown 17y ago
    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.
  - corysama 17y ago
    Lua has a simple API for debugging built in. Because of this, there are several free and a few commercial Lua debuggers available.