Computer Science Canada Opinions; Choice of scripting language |
Author: | btiffin [ Mon Oct 27, 2008 5:24 pm ] |
Post subject: | Opinions; Choice of scripting language |
Hello everyone, I'd like your opinion on choice of embedded script interpreter for a compiled language. Just for arguments sake, let's say that language is COBOL. So far I've got proof of concept layers for embedding;
Others are already hard at work adding pgSQL and a perl interface. And I was wondering what would/could be an OpenCOBOL uptake attractor for respectable developers such as yourselves. I've got some spare time to twiddle and I'm leaning toward offering another embedding choice to OC programmers. LUA? Ficl? Falcon? To name a few ... I'd prefer to hear your take on it. Python? BOO? As an FYI, the SpiderMonkey engine and Tcl/Tk are both being given a nice professional polish, so they will be (optionally) provided along with OpenCOBOL at some point. SQLite is already more than usable, but data scripting and open scripting are two different animals. I'd love to go embedded Ch, but it's commercial. LUA? Cheers and thanks in advance if you take the time to opine Edit; typos (always with the typos) |
Author: | Euphoracle [ Mon Oct 27, 2008 6:35 pm ] |
Post subject: | RE:Opinions; Choice of scripting language |
Personally, I love Lua. I'm totally biased towards it because I've used it both other people's work and my own (in C# at least) and it's such a nice language to work with both in the actual "code" and in the scripting code. It's elegant and human. Overall, I think of it as the ideal scripting language for me. It makes extending an application a breeze when implemented correctly* and has a very pretty and usable scripting syntax that's easy to follow. The mixmatching of types can sometimes produce cases where you have to doublecheck what's coming in from the scripting end, but other than that, it's just such a delight to use. It can be used to produce complex scripts (Tables are made of pure, liquid-cooled awesome) or simple, linear scripts. Hurray Lua ![]() |
Author: | wtd [ Mon Oct 27, 2008 7:02 pm ] |
Post subject: | RE:Opinions; Choice of scripting language |
Ruby, Io? |
Author: | Zeroth [ Mon Oct 27, 2008 7:26 pm ] |
Post subject: | Re: Opinions; Choice of scripting language |
Lua. It has simply the smallest engine of all scripting languages. It has a nice, recognizable syntax, and it features coroutines. |
Author: | btiffin [ Mon Oct 27, 2008 8:08 pm ] |
Post subject: | RE:Opinions; Choice of scripting language |
Ok, Lua is the next on the plate for a proof of concept pass. And reading the About page, I've been misspelling it as an acronym. Smackdown! My apologies to the Pontifical Catholic University of Rio de Janeiro. Won't happen again. And please don't take this post as a sign that I don't want more opinions. Gee, I might even listen to wtd and look into Io. Ruby? rebols dislike Ruby. Why? Jealous. Thanks gentlemen, Cheers |
Author: | Zeroth [ Mon Oct 27, 2008 9:02 pm ] |
Post subject: | Re: Opinions; Choice of scripting language |
And after Lua, get Python. After Python, make a .net version of OpenCOBOL. EDIT: To be more specific: Python is considered the industry's glue language. Having bindings will make OpenCOBOL marginally more attractive. And the same goes for a .net version of OpenCobol. .net is the up and coming contender for universal VM(the previous holder is Java). |
Author: | btiffin [ Tue Oct 28, 2008 1:40 am ] | ||||
Post subject: | Re: Opinions; Choice of scripting language | ||||
Lua ... nice ... a little bi-polar it seems; the changes between 5.0 and 5.1 being non-trivial when mixing and matching docs to code. lua_dofile versus luaL_dofile ... oh well, can't hold back progress. 5.4 will have to wait till a few test heads are set up.
gives this output with a quick test wrapper - a c function as object file and COBOL caller with a pic x(32) result field pulling top of Lua stack
Thanks for the comments ... and please feel free to continue with opinions Cheers P.S. Zeroth; I'll disagree a little with the industry on considering Python the "glue". C is the glue. Python enables higher level abstractions and tool access sure ... but you can't (easily) write a mixed-language wrapper in Python (well, not that I've seen ... if it supports ELF, I take that statement back). Then again, I disagree with the industry at least twice a day; while waking up and while falling asleep. ![]() Having said that, next time I'm twiddling, Python may get a wrap. I'm a fan of Guido's work. |
Author: | Zeroth [ Tue Oct 28, 2008 9:18 am ] |
Post subject: | Re: Opinions; Choice of scripting language |
btiffin @ Mon Oct 27, 2008 10:40 pm wrote: P.S. Zeroth; I'll disagree a little with the industry on considering Python the "glue". C is the glue. Python enables higher level abstractions and tool access sure ... but you can't (easily) write a mixed-language wrapper in Python (well, not that I've seen ... if it supports ELF, I take that statement back). Then again, I disagree with the industry at least twice a day; while waking up and while falling asleep. ![]() Having said that, next time I'm twiddling, Python may get a wrap. I'm a fan of Guido's work. Well, considering some very large and profitable companies use Python as their glue language I'd take that as a hint. Industrial Light and Magic, NASA, Civilization 4, Rackspace, though granted NASA's not profitable. Now while it is not extremely common, I've seen evidence that it is becoming more common. There are countless small companies that use Python for a wide variety of purposes that don't ever get talked about. Everything from generating dummy images/sounds to handling XML conversion, to writing Webspiders. And lets not forget Google! |
Author: | btiffin [ Tue Oct 28, 2008 12:24 pm ] | ||||
Post subject: | Re: Opinions; Choice of scripting language | ||||
Sorry Zeroth; I guess I should have been more clear. Yes, I agree the industry believes Python is glue, I disagree with that belief. ![]() But now for something completely different; you may be able to help me out;
Please ignore all the cruft ... this is my learn by experiment file. My goal is to allow Python scripts to be interpreted, then pass the data back to an OpenCOBOL alphanumeric field (think char array). And at the Very High Level of embedding. So given that I want to be able to execute arbitrary Python code (not knowing the type of the result of the script) what should be in pystring in this case? I'd expect a formatted datetime string, but the actual result from PyRun_String is coming back as "None". So, what am I missing? Using
as the last script line ends up returning <NULL>. I want the datetime string (or whatever value an arbitrary script may return) to come through as the result. Do I need to access a special variable in the global dictionary? And yes, I have more to learn ... this is experimental so no safety checks are in place yada yada. Cheers Edit; Learning more. I think I'm starting to see the intent of the Python API ... so perhaps the High Level embedding isn't going to cut what I need. I'll either cheat and document the OpenCOBOL interface as requiring an opencobol = ... somewhere in the script and pull that value out of the dictionary, extend Python with a returntoOC() function or burden the OC developer with the deep interface and expect them to name the function they want evaluated and use the proper API calls to retrieve the results. I'm leaning toward the easy cheat of opencobol = ... for the proof of concept pass. Thanks again and I'd still appreciate other points of view on what people here would appreciate having access to for scripting within a compiled environment. |
Author: | Zeroth [ Tue Oct 28, 2008 7:42 pm ] |
Post subject: | Re: Opinions; Choice of scripting language |
Take a look at this short discussion. The most python embedding I've ever done was writing a C module for an app that already had python embedded in it. :/ http://mail.python.org/pipermail/python-list/1999-April/000154.html |
Author: | btiffin [ Tue Oct 28, 2008 8:28 pm ] |
Post subject: | RE:Opinions; Choice of scripting language |
Thanks Zeroth; read that one. It was one of the clue threads that I was wrong thinkin' in my expectations. Always with the ditto and the Zeroth ![]() Cheers Edit; Adding Anyone that cares; OpenCOBOL Lua interface Still undocumented, lacking a few safety measures in the code, at least one more pass before it gets bundled. http://www.opencobol.org/modules/newbb/viewtopic.php?viewmode=flat&topic_id=395&forum=1 |