Designing a Programming Language For Embeddability 52
CowboyRobot writes "The creators of the Lua language describe the process of designing a new language and the constraints that certain parameters, specifically embeddability, place on the process. 'Many languages (not necessarily scripting languages) support extending through an FFI (foreign function interface). An FFI is not enough to allow a function in the system language to do all that a function in the script can do. Nevertheless, in practice FFI covers most common needs for extending, such as access to external libraries and system calls. Embedding, on the other hand, is harder to support, because it usually demands closer integration between the host program and the script, and an FFI alone does not suffice.'"
Oh good (Score:1)
Oh good, another language.
Re:Oh good (Score:5, Informative)
Re: (Score:3)
Bah. Newfangled crap. I'll stick to COBOL, thank you very much.
If they are going to, might as well do it right. (Score:4, Interesting)
Since it's a given that people are going to be creating new languages, I certainly hope they listen to what Roberto has to say. Lua is a joy to embed into applications compared to python and others.
Worst (Score:1)
Re: (Score:1)
I think the main reason Lua doesn't have a stable IR form is because in practice there simply isn't a need for the kinds of optimizations it would enable. Lua firmly establishes itself as an embedded scripting language, so in nearly all practical cases whatever Lua code is included in your application represents a negligible amount of resources used (or at the very least isn't one of the big bottlenecks). This is on top of the fact that Lua code already is very fast for a scripting language. If Lua performa
Forth (Score:4, Informative)
Re: (Score:1)
Except this is not about languages running on embedded platforms, this is about hosting a language inside an application, for providing e.g. scriptability of a GUI application.
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Loeliger's book 'Threaded Interpreted Languages' was one of my favorites non-fiction books ever. (Yes, I am that geeky).
Reading how he started with just a few tens of opcodes and chapter by chapter boot-strapped an entire operating environment was like reading Genesis.
Re: (Score:2)
Re: (Score:2)
if your going to write small blazing fast code you need to go old school. http://www.amigacoding.com/index.php/680x0:AsmOne [amigacoding.com] it comes with its own IDE!
Re: (Score:1)
Inferior to what?
Re: (Score:2)
It would be helpful if you included some details.
Re: (Score:2)
World of Warcraft uses LUA for mods, and noone seems to be having any problems with it. If anything, theres too many mods.
Re: (Score:2)
Hilscher uses it in some of their communications gateways. From my personal experience in one particular application, the interpreter was too slow to move all the bits and bytes that had to be moved between two systems speaking different protocols, while keeping the communications (machine) cycle at 1ms. YMMV of course, so this is just a specific case, not a generalization.
I think it'd have been much easier for me as a customer if they simply provided an export library exposing relevant APIs in their firmwa
GRUB? (Score:2)
So what happened to Lua support in GRUB? I saw some pretty nifty things done with that.
Lisp (Score:3)
Comment removed (Score:5, Informative)
Re: (Score:1)
"The default method is to have development write a new command, check it into source code control, have QA run through it, approve it with the release schedule, then release it to manufacturing. Alternately one could just write a quick script and use that instead if the boot loader supported a scripting language, and manufacturing could manage this themselves without begging for R&D resources."
This means that your development/release process is broken with respect to your business needs, not that you ne
Re: (Score:2)
We have a prefix-form for math, observe:
add 3, 5, 10
multiply 2, 2, 2, 2, 2
etc.
Math is really the only thing we use infix for and if you discuss it using prefix operation, as above, nobody has a problem understanding, and therefore getting how lisp works. (add-this-list 1 2 3)
LISP's lispisms really only bug other, often narrowly skilled, programers who can't imagine another way to do anything. To someone learning from scratch it's so simple its oddity is of little importance.
Well, huh... You don't say. (Score:2)
So, if you design your DSL based on the D, it will effect the S of your L?
Who'da thunkit?
Embeddibility? (Score:1)
After reading the headline, am I the only one that thought embedded in the context of microprocessors instead?
Self-morphing languages (Score:2)
What's the track record for self-morphing languages like Lua and Forth? I just skimmed a Scala book, and it scares me.
I can see niches like producing DSLs, but smells like bad news for general application/system programming.
Tcl (Score:2)
http://sourceforge.net/projects/tcl/ [sourceforge.net] says: "Tool Command Language (Tcl) is an interpreted language and very portable interpreter for that language. Tcl is embeddable and extensible, and has been widely used since its creation in 1988 by John Ousterhout. See http://www.tcl.tk/ [www.tcl.tk] for more info." Another good source of information on Tcl is http://wiki.tcl.tk/ [wiki.tcl.tk]
Tcl functions well as glue between applications. Some folks know Tcl but call it "Expect" and may not realize Expect is simply Tcl plus an extension. Anoth
fanwagon (Score:2)
There are lots of peeps pushing FFI, it's a bunch of crap IMO. They never seem to have any reason except portability, and they always try to hide or deny that it is slow and not very powerful.
There are already so many C libs, actually doing anything with it requires re-inventing all your wheels, and the wheels to make those wheels.
If C is too hard, you're not going to be doing embedded stuff long enough to get good with FFI anyways.
Really you need to design your application round (Score:1)
Really you need to design your application round your embeded scripted language. If added as an afterthought it becomes a "lowest common denominator" interface between your application's type model and the embeded language's.
tcl (Score:2)
i know, that will be hard to swallow, and tcl is not one of the , favourite 5 programming languages of mine, but its stable, easy to embed, has clear interfaces, and is leightweight. What else do you need?
Re: (Score:2)
Tcl is indeed an excellent choice for many embedded applications. It's not as trendy as many of the newer languages, but it is an awesome tool for getting a lot done with a very small amount of code (some joke that it stands for "Try Coding Less"), and with very minimal overhead.
Lua's certainly intriguing, and I might look at it for future projects, but the vast majority of what I've had my teams build in the past few years is Tcl (if small size is important), or Python (if it's less important).
Like Python