Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Lightweight Scripting/Extension Languages? 176

Posted by Cliff from the when-the-code-footprint-is-everything dept.
Andy Tai asks: "Extension languages are designed to be embedded in applications to support customization of the application behavior. Common scripting languages, like Perl and Python, are fairly 'large' with powerful run-time engines and libraries and are widely available and 'script' writers usually assume their stand-alone existences in the deployment environment. However, if one is looking for a language that's small enough so its source can be embedded in the distribution of and built as part of the application, Python and Perl may be 'overweight.' For the real lightweight choices there are Lua and Tinyscheme. Are there others? What are people's preferences and opinions regarding lightweight extension languages?"
This discussion has been archived. No new comments can be posted.

Lightweight Scripting/Extension Languages? More

Lightweight Scripting/Extension Languages?

Comments Filter:

  • Anything but odd/new language... (Score:3, Insightful)

    by cymen ( 8178 ) <cymenvig.gmail@com> on Tuesday January 06, 2004 @01:55AM (#7888919) Homepage
    Is PHP/Perl/Python too big? Just use them. I don't care about a couple more megs of system RAM. RAM is cheap. Learning a new language takes time.

    Unless there are extremely good grounds for using some annoying new/odd language, use something mainstream.
    • I would agree with this, except that it makes for somewhat inefficient programs when one blows a couple extra megs of ram. Efficient, small programs are better long run because they are easier to maintain and run faster. However, for a hack, macgyver job nearly anything can be used.

    • Re:Anything but odd/new language... (Score:2, Informative)

      by Anonymous Coward
      Assuming you already know at least one other language, learning LUA takes exactly 1 hour. That's it. Spend an hour on it, and you are a master LUA programmer. That's a big part of its appeal.

      • "...learning LUA takes exactly 1 hour."

        I couldn't read the reference manual in one hour. I couldn't learn the quirks of co-routines in one hour.

        I think there is a big, big misunderstanding about computer languages. The "quick and dirty" ones are incomplete and limited. The complete languages are necessarily complex. At one time, Perl was like Lua. Then it needed this and that until now it is beginning to be as complex as C++. The same will happen with Lua, I'm guessing, if it remains popular.

        It

        • EiC? (Score:3, Informative)

          by Futurepower(R) ( 558542 )
          Or, how about EiC [linux-mag.com], now hosted at Sourceforge [sourceforge.net]. "EiC is pointer safe."
        • Great so Pascal is dead. Great example. What about all of the languages people learn that did not die? Java? Perl? C++? Python? PHP? What about the millions people who productively coded tens of millions of lines in languages that were invented since 1972? You can live under a rock pretending that C is good enough if you like but the rest of industry is going to keep learning new languages, improving its productivity.

          • Pascal wasn't just any language. It was the most taught computer language in the world at one time. It died within a few years. No one seems to be mourning it. So, how many languages do we really need, if one can die without causing problems?

            My vote: Put all the good stuff into one language.
        • I'm tired of learning new languages. I don't see the point in it.

          Fun. Brain excercise. It makes you a better programmer in general even if you don't end up using that language.
          I can almost guarantee that if you took any Java/C programmer, taught them some Scheme and Forth, they would end up being a better Java programmer for it.
      • Don't get me wrong, Lua is an awesome language. Tiny, but not pokey, quite flexible- a real language. Yes, you could learn the basics and be writing some code in an hour, but you could never master it. The only language I know that could be mastered in an hour is PILOT.
      • I wouldn't say learning Lua takes an hour, but it is a very nice language and specifically designed for embedding - amazing that it's not mentioned more. It's used by Tomsrtbt (Linux boot disk) for its incredible compactness - many of the Linux utilities are re-implemented as Lua scripts - and by many applications as an extension language.
    • Is PHP/Perl/Python too big?


      Yes, it's HUGE, when you're adding it to the software you've written yourself; and it's seriously overkill if you only want people to control a few things inside you're own program.

      Take a look at AppleScript [apple.com], a beautifully simple way to control GUI-apps on a Mac.
      • And what's even cooler about AppleScript is that there is more to it. AppleScript is merely the default plug-in for the Open Script Archtecture (OSA) into which other languages can plug. I've seen Tcl, JavaScript, Perl and Ruby and there are more. Allows those other languages to call into your Mac apps in the same way AppleScript can- slick as snot man.
      • Yes, it's HUGE, when you're adding it to the software you've written yourself; and it's seriously overkill if you only want people to control a few things inside you're own program.

        No, it is NOT huge. 300 MB is huge, 2-3 MB is peanuts. The loss of efficiency to my brain having to learn a new language is much greater than the loss of efficiency to my computer having to use a couple more megs of RAM. Stop punishing your users.
    • I agree - especially as python can be really tiny.

      Also, read this:

      Extend vs Embed [twistedmatrix.com]

      Often people only think of putting python(etc) inside their program, rather than the other way round - putting their program inside of python. Read the above link.
      • It's a good rant but it's not really very relevent - writing your app in python (at least in the way he describes) simply isn't plausible if you're writing an app for commercial or even mass distribution - you can't rely on an existing Python installation and if you've got to package one with your installer then theres hardly any more work to embed an interperter instead.

        Thinking on the popular applications out there that I know of that embed Python, you wouldn't want to write ANY of them in Python. Blende

        • I think you misunderstand.
          say I have a program, written in C, and I want to add full python scripting support.

          One way would be to try to add in the python interpreter into the program, and this is the way you immediately think of.

          The second way would be to have a small python program that calls your program (so all you rewrite in python is your main() function and the function that does event handling.)

          The link I provided gives reasons on why they consider the second way better.
        • "It's a good rant but it's not really very relevent - writing your app in python (at least in the way he describes) simply isn't plausible if you're writing an app for commercial or even mass distribution - you can't rely on an existing Python installation and if you've got to package one with your installer then theres hardly any more work to embed an interperter instead."

          This is old enough it will probably never be read, but that isn't true. There are utilites that do this in a snap, in addition to findi
    • There are dozens of available library implementations of reasonably well known languages. The trick is simply finding which one fits best for you. And, depending on the application, and how it's used, you might want to consider created a more generalized plug-in architecture, and allow for multiple scripting languages (possibly using something like CORBA).

      One thing I would strongly urge, is to pick a "real" language that already exists. Ideally, something like those listed below. Even if it's a fairly

      • * Scheme, due to it's small size and powerful, easily extendable syntax, seems to be quite common when it comes to extension langauges. A list of programs that use Scheme (or a similar lisp dialect) off the top of my head includes: SIAG Office, The Gimp, Emacs, TeXmacs, Gnumeric, AutoCAD, Sawfish, GnuCash, Snd Sound Editor, etc.

        Well, add Cadence (one of prolly 2 or 3 top-notch IC (ASIC) design suites, sellable to the tune of couple 100,000/seat) to the list, and take AutoCAD off (it's not really Scheme,
    • You know... most of the size of embedding Python is from the default library, which does not need to be included for embedded scripting. The actual binary of the python interpreter is barely over 20k.

      There's no reason *not* to use Python for your embedded scripting, IMO.

  • Guile (Score:4, Informative)

    by crmartin ( 98227 ) on Tuesday January 06, 2004 @01:57AM (#7888926)
    God knows the words "lightweight" and "Gnu" don't generally go together, but how about Guile [gnu.org]?

  • TinyTCL (Score:3, Informative)

    by the_womble ( 580291 ) on Tuesday January 06, 2004 @02:05AM (#7888955) Homepage Journal
    what about Tiny TCL [sourceforge.net]

    Its easy to learn and use (very good if the people using our embeded language are not programmers). Its mature, supposed to be extensible, and if you decide you need something more powerful later on even the current full verion is not that bloated.

    • Re:TinyTCL (Score:5, Informative)

      by Twylite ( 234238 ) <(twylite) (at) (crypt.co.za)> on Tuesday January 06, 2004 @02:36AM (#7889058) Homepage

      Tcl/Tk [www.tcl.tk] proper is not a bad idea either. If one does not need the GUI part (Tk) then Tcl is relatively easy to integrate into a project, and is under 200k.

      HowToEmbed [wiki.tcl.tk] from the Tcl Wiki is a good starting point, and MkTclApp [hwaci.com] may help.

      Tcl has very consistent and simple syntax (although it can get rather confusing at times), and it is very simple to add new command into your application that are exposed via Tcl. One of the nicest aspects of Tcl is that is it seriously multi-platform.

      Of course this all depends on the requirements: how powerful does the language need to be, what functions must it provide, what types do you need it to be able to handle, how small is "lightweight", etc.

      • Re:TinyTCL (Score:5, Informative)

        by ianezz ( 31449 ) on Tuesday January 06, 2004 @04:32AM (#7889411) Homepage
        One of the nicest aspects of Tcl is that is it seriously multi-platform.

        Another nice aspect of Tcl is that it can easily evaluate code in a different stack frame (example: in the caller's context), and source code can be easily passed to procedures as strings between braces (as it is usually done), so extending/reimplementing the language control structures is as simple as writing a new procedure (and no special/ugly syntax is required).

        That's as close to Lisp macros as you can get.

        • It may be better now, but it used to be a huge pain in Tcl to get things to evaluate in the context you wanted, because it doesn't have lambdas/closures. The "everything is a string" approach works ok for small programs and makes the learning curve shallow, but I found I hit a ceiling really fast. The only good thing about Tcl is that it comes with Tk, but since Tk is accessible from other languages, like Python and Perl, I'm happy to avoid Tcl.

          YMMV, of course, but I prefer a language with real control str

  • Just how much customising do you need?

    From my experiance if you only need a little customisation then you can do most of that stuff from a config file, .ini if you want it to be easy to edit, xml if your going to write a gui to do it or your users are compertant. Any more than that your better off going with something like python or perl, they are widely known, and have rich libraries to let the people using the app do some really imaginative things.

    The other thing that you can do is write your app in

    • Multi-language capability gets slammed with the argument that 5 different programming teams within an organization are going to write in 7 different languages, and how do you maintain that mess. To me, multi-language means I write the app in whatever language suits me, and users of my app write scripts and extensions in whatever language suits them.

      COM/ActiveX works swimmingly in this regard in that you have a choice of languages for both producing and consuming COM/ActiveX components, and COM allows you

      • Multi-language capability gets slammed with the argument that 5 different programming teams within an organization are going to write in 7 different languages, and how do you maintain that mess.
        For many organizations, the issue is hiring and efficient staffing. If you have 7 languages, but you can only find programmers that know 3 of them, then you can only use those programmers for some of your projects. They go without work while you can't even find staff for some of your other projects.

        The place where
        • I presented 5 teams and 7 languages as a strawman argument. I am advocating that I develop applications or applications as a collection of software modules in the language I work with best, and I offer clients developing extensions using those modules the option of using whatever (one) language they work with best. It seems every time I advocate this approach people, come back at me with the "5 teams and 7 languages" as a bad way to develop systems -- that is not why I want multi-language.

          SUN and Java i

  • The need for "extension languages" (Score:5, Insightful)

    by be-fan ( 61476 ) on Tuesday January 06, 2004 @02:26AM (#7889030)
    Is usually a sign that you are using too low-level a language for the application itself. There is no reason you can't write your whole app in something like Python (or better yet, a compiled high-level language).

    I can see why you might want to stay with C/C++ for a major commercial application (not because of speed reasons, but because the maturity of the implementations of alternative high-level languages) but it pains me to see tons of OSS software, especially non-speed-critical GUI apps, still being written in C!

    • Re: (Score:2, Funny)

      by account_deleted ( 4530225 )
      Comment removed based on user account deletion
      • Well C is quite nice, but there are lots of languages that will get you 80-90% the performance of C, at a much lower investment in time. I'm a performance freak too, but after seeing what d2c (the Dylan compiler) and sbcl (a CL compiler), I know longer consider performance a downside of using a higher-level language.
    • I agree: the use of C/C++ for most Linux applications just doesn't make a lot of sense. It's more effort to develop in than a HLL, a lot harder to debug, and usually, it isn't even any faster. Python would probably be a good choice for many desktop apps.

      However, when it comes to statically type checked, non-C/C++ languages on Linux, there isn't much choice:
      • Java: no fully compliant open source implementations; some serious design flaws.
      • C#: not a standard part of major Linux distributions; some concer
      • you know, i think you're spot on the money with this comment. i can program in several languages (though no functional languages i'll admit), in my 5 odd years of professional programming, i don't think there's a single language that one could say is uniformly good for all tasks. which is kindof surprising, since it is easy enough to envision that a language could be more-or-less extended/tweaked without limit by extension modules.

        java could and *should* have been it, but as you say, some idiotic design de
    • I don't think you're visualizing the situation correctly.

      I don't see how the need for an extension language indicates that at all. An extension language (IMHO) is usually needed so that the end user of the application can script that app and extend it to do things you, the application engine writer, did not supply. The needs of the engine and the needs of the extension language are totally different.

      I'm going to want to write the engine to be fast,
      efficient, and easy for me to maintain. The extension m
      • If you accept the notions that
        1. scripting languages speed development
        2. high-level code does not need to be optimized

        Then for an app like Neverwinter Nights, it would make sense to use a scripting language for the high-level code (e.g. menu handling code), while leaving the performance-critical code (e.g. 3-D rendering) in C, C++ or assembler.

        Coded like this, NN might not crash as frequently because either
        - The crashy code would be implemented in a scripting language, and so memory handling would not be
        • You neglect the fact that high-level code *can* be optimized. Major PS2 games (Jak and Daxter, I think) have been written mostly in Common Lisp. You'll probably still need assembly on some critical inner loops of the graphics engine, but then again, C code on the PS2 uses assembly on inner loops to take advantage of the vector units.
          • You neglect the fact that high-level code *can* be optimized.

            Any code can be optimized, but the question is whether it should. Code optimization (as opposed to compile-time optomization) should only be done where it has a noticeable impact on performance. Most code does not have an obvious impact on performance, and so it should be left alone, so it's more readable.

            If your high-level code has a significant performance impact, it may not be as high-level as you believe.
            • I mean compiler optimizations. High-level language compilers these days are good enough that you can write performance-sensitive programs like games in these languages. It was a response to the OP's reference to using C/C++ to write performance-sensitive parts of games.
              • In my experience that's rarely true. For example, the Python compiler does barely any optimization when it generates bytecode, if it does any at all - recent versions did not. Interperted/VM languages are cost-effective now because of the low price of memory and CPU time, not because of magical optimizations. Sure, you can do some spiffy stuff with JIT, but it's a very rare win over compiled code. You can write 3d rendering engines in Java, if you need to - it's a hell of a lot slower than comparable C code
                • I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

                  In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compi
                  • I believe all of these are very true; HLL's can be optimized, and in some cases perform very well, far beyond the usual off-the-cuff expectations for HLL performance.

                    However... then we get into a situation where the programming team has to ask themselves:

                    - Do we know the language well enough to program in it without increasing our development time?
                    - If not, would the increase in time on this project end up benefitting us on the other projects in the pipeline? (Do we even have a 'pipeline'?)
                    - Do we know

  • Javascript! (Score:5, Interesting)

    by Geek Boy ( 15178 ) on Tuesday January 06, 2004 @02:48AM (#7889093)
    ECMAScript/Javascript seems like a logical choice. it was made for just that - embedding. It's quite small to implement, and there are many opensource implementations out there already. It can be procedural or OO, and everyone knows how to use it if they've done some basic web work.
  • I find s-lang a very nice extension language. www.s-lang.org

  • ICI (Score:4, Interesting)

    by tpv ( 155309 ) on Tuesday January 06, 2004 @02:49AM (#7889100) Homepage
    ICI [sf.net] is very lightweight and generally quite usable by semi-programmers.

    It's sufficiently C-like to suit anyone who has done C/C++/Java/Perl/... but high level enough to be a feasible extension language.

    Of course it depends on what type of person you expect to use your extension language. Are they programmers?

  • paxscript (Score:2, Informative)

    by glob ( 23034 )
    i recommend you look at paxscript [paxscript.com].

    it's the most complete and quickest of any embedded source stuff that we've investigated.

    supports basic, c, objectpascal (ie delphi) and javascript.

    not free, but you get the source when you purchase it (US$179).

    delphi and borland c++ builder only.

  • REBOL (Score:3, Informative)

    by the_greywolf ( 311406 ) on Tuesday January 06, 2004 @03:29AM (#7889237) Homepage

    didn't see anyone else mention it, so i thought i would.

    REBOL [rebol.com] is a ridiculously simple and easy-to-learn web-oriented language. so easy, in fact, that i wrote a fully-functional IRC dice bot in under 400 lines, overnight. and if that weren't impressive, then might i add that i was running on ZERO caffeine, learning the language for the first time, learning IRC Client protocol for the first time, and came up with a few unusually witty statements and insults to boot?

    now the bad part: REBOL is not open source. poo. (i really was a bit disappointed.) but REBOL/Core is free (for any use, i gather), and the license fees for View and Command seem rather reasonable.

    the nice part: it has been ported to and runs on about 43 platforms, last i checked, and is light enough that the executable weighs in at around 250kb for the win32 release. (haven't used the other platforms, so no comment.)

    it runs on just about every unix i've heard of, on every relatively common configuration, and works beautifully and seamlessly. and, after a quick glance, i see it runs on serveral major embedded systems, including WinCE, QNX, and Linux, and will even run on my friend's dated Amiga.

    enjoy and happy coding. :)

    • Re:REBOL (Score:4, Informative)

      by swdunlop ( 103066 ) <swdunlop AT gmail DOT com> on Tuesday January 06, 2004 @06:35AM (#7889763) Homepage
      I had a very guilty love for REBOL, but it hasn't changed much in the last three years.. Many of the warts on REBOL/View are still there, and it's still not fully documented. They also haven't finished their port to OS X, so it isn't as perfectly cross platform as I would like..

      And.. Finally.. How does one embed REBOL in an open source application?
      • Using R#. the sharp has nothing to do with .NET, mind you. It's an open source REBOL implementation, not sure how done it is- it's a 0.5-0.6 last time I used it. I've just stuck to using the real thing myself.

        But I too have had the same guilty-love of REBOL. It is a very capable and handy language, definately one of the more useful so-called "scripting" languages I've ever seen or used.

        Other than this, there is no way to embed REBOL in an app directly, though you could call the interpreter over a pipe. Yo

  • Developing for windows? (Score:5, Informative)

    by KILNA ( 536949 ) * on Tuesday January 06, 2004 @03:43AM (#7889278) Journal
    TinyPerl [sourceforge.net]

  • Object Forth? (Score:5, Informative)

    by samjam ( 256347 ) on Tuesday January 06, 2004 @04:09AM (#7889356) Homepage Journal
    ficl.sourceforge.net [slashdot.org]

    A portable object oriented forth at less than 100K for a full implementation, able to handle calls from your apps as well as call your apps fgunctions or other dll's.

    Under a BSD-ish license.

    The upside:
    1) Its tiny
    2) The forth code you write will be tinier

    Downsides:
    1) You need to learn forth (I mean properly) to appreciate it.

    Forth is unlike most other languages, it was designed to avoid the debug, recompile cycle that is so common.

    Sam

  • How about JavaScript? (Score:5, Informative)

    by Rich ( 9681 ) on Tuesday January 06, 2004 @05:26AM (#7889560) Homepage
    I've been working on a system for embedding JS in KDE apps (amongst other reasons it is a about 1/10 the size of a python interpreter). You can find lots of information at http://xmelegance.org/kjsembed [xmelegance.org]. The interpreter in KDE has no dependency on KDE/Qt or anything else so you might find it usable in your app.
    • The problem I've been having is that I mainly write in C++, and all the scripting languages I'm aware of only have the ability to call C interfaces, even the object oriented ones. Shouldn't it be possible to implement an interface to the C++ ABI so you can (semi-) directly map scripted objects to C++ ones without the annoyance and overhead of flattening to C (via SWIG or whatever)?
      • I do a similar thing. I've developed a tool that uses doxygen to generate XML descriptions of the code, then xslt to create a binding to JS. This isn't 100% automated yet, but I was able to bind a fairly complex class (QDir) in about 20 minutes. This includes all the enumerations and default argument support.

        Rich.
        • Thats a cool idea. You might want to take a look at gcc_xml (which I haven't had a chance to work with in depth yet), which patches GCC to output an XML representation of your code.
          • You're the second person so suggest that, I haven't had a chance to look at it yet. For now the doxygen solution works nicely and has the advantage of understanding signals and slots.

            Rich.

      • I think Boost.Python [boost.org] does what you're asking.

    • If the KDE folks shipped Python with the KDE desktop (small in comparison) then every KDE app would have access to a much more powerful embedding language, which already has KDE, QT and DCOP bindings, a powerful library and all of the other good stuff that makes Python more popular for scripting than Javascript (off-Web).
      • There are a number of problems with that:

        1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).

        2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).

        3. We would have huge version skew problems because the distros (and us
        • 1. The kjsembed library provides access to the existing objects with no (repeat *no*) need for the host app to write any extra code. ie. it can extend apps that were not intended to support this stuff (though obviously it is better if they are).

          If the bindings are already there, why couldn't this be extended to another language as well?

          2. A huge proportion of kde apps already link kjs via either khtml or via kdeinit. This adds no extra overhead (rather than a large python interpreter).

          Python can work

  • Copy of an advogato article (Score:4, Informative)

    by DavidNWelton ( 142216 ) on Tuesday January 06, 2004 @05:29AM (#7889572) Homepage
    I guess atai must have submitted the same question here as well, but the "original" discussion took place on advogato:

    http://www.advogato.org/article/735.html [advogato.org]

    It would be useful if he could state what his requirements and limits are, in detail, because that's a very necessary part of evaluating what would work.

  • Why another language? (Score:5, Insightful)

    by Anonymous Coward on Tuesday January 06, 2004 @06:21AM (#7889723)
    Extension languages are designed to be embedded in applications to support customization of the application behavior. Common scripting languages, like Perl and Python, are fairly 'large' with powerful run-time engines and libraries and are widely available and 'script' writers usually assume their stand-alone existences in the deployment environment.

    Well you're not obligated to provide the libraries. For instance, Blender, which uses Python, did not include Python libraries ; however it was possible for people which really wished it, to set paths to point to libraries. Forcing the users to learn a new language, just to cut the size of the distribution is misguided IMHO. Just provide the extension language (& support) as an optionnal individually downloadable shared library.

  • Consider Ruby (Score:3, Informative)

    by urbangipsy ( 301283 ) on Tuesday January 06, 2004 @07:20AM (#7889897)
    What about Ruby (ruby-lang.org [ruby-lang.org]). It's easy to learn, powerful and has a reasonable set of classes and methods built-in. It's also quiet widespread nowadays, lightweight compared to Python and easy to embed via libruby.so
    see the Ruby book [rubycentral.com] (section Embedding a Ruby Interpreter
  • On Mac OS X you definitly will use AppleScript. Regardless of programming language used for your application. OTOH, you can use any language that offers a library to send high levle events to your apps(not sure about that in our days).

    On Windows you likely will use Visual Basic for Applications or Visual Basic Script or any other Active Scripting language.

    If you write ONLY Java, like I do in our days, its easy: the scripting language will be either Java(Dynamic Java, see: http://koala.ilog.fr/djava/ or Bean Shell, aka bsh, see: http:www.beanshell.org) or Java Script, aka Rhino, see: http://www.mozilla.org/rhino/ or any other language running on a JVM see: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml

    If you write your program ina C-ish language I would consider to use CORBA --- yes indeed!! --- to be able to script it with everything.

    If you want to use traditional scripting languages like TCL, PERL etc. you likely will want to look into SWIG, see: http://www.swig.org.

    But ... as soon as you start working with SWIG you will realise that making an application scriptable menas to craft special hook functions to access only the wanted part of the application, likely via strings only arguments and return values.

    The bigger your applicatin gets, the more complex will be the access layer for the scripting languages.

    When you have reached that point you likely regret not to have used something more suiteable, like CORBA or the Java stuff I sketched above or you are to the point where you throw it away and rewrite it in a "embed" approach where you will use a scripting language as development language and write certain modules as plugins into that language.

    Then however you are bind to the scripting language as host language.

    BTW: there are a lot of free mini orbs which make CORBA a toy. And writing IDL is not much harder than writing SWIG config files. If you like to shield your customer from CORBA give him a lib for his scripting language, which hides the fact that CORBA is used.

    Regards,
    angel'o'sphere

    • If you write ONLY Java, like I do in our days, its easy: the scripting language will be either Java(Dynamic Java, see: http://koala.ilog.fr/djava/ or Bean Shell, aka bsh, see: http:www.beanshell.org) or Java Script, aka Rhino, see: http://www.mozilla.org/rhino/ or any other language running on a JVM see: http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.ht ml

      You forgot a big one: Tcl. There is a pure Java Tcl interpreter Jacl [www.tcl.tk]. It's trivial to embed and use. I've used it to add scripting to tools, and t

  • Perl 4, while dated for newer Perl programmers is a very effective language and weighs in around 400k.

    I can think of a couple of big, $$ applications that embed it.

  • Nasal, a javascript-like language (Score:3, Informative)

    by truth_revealed ( 593493 ) on Tuesday January 06, 2004 @09:05AM (#7890479)
    Nasal [plausible.org] is a very well designed small embeddable language with a Javascript-like syntax and an LGPL license. I prefer it to Lua because I am not fond of Lua's Pascal-style syntax. Be aware that Nasal is not very battle-hardened yet and does not have even a 1/100th of the developer community of Lua.

  • LUA (Score:2, Informative)

    by schapman ( 703722 )
    lua is a great scripting language when it's used well. When i was studying game development in school, we were introduced to it as a good way to drive out games. Its easy to add functionality for it... its fast... it simple. I could write all my rendering/sound/network/input code in c++, and just have interfaces for everything from lua... this way, when i wanted to drive a game app, i could do the following: (pseudo lua... hmm... pseudo scripting :) ) load level load char at xyz load enemy at xyz go then,

  • Nasal (Score:3, Informative)

    by Nevyn ( 5505 ) * on Tuesday January 06, 2004 @11:48AM (#7892273) Homepage Journal

    When I was answering this question, I ended up looking at nasal [plausible.org]. While not perfect, it was the closest to what I wanted ... and was under a compatible license (LGPL). But then I wanted something small, lua is way too big.

  • TCL! (Score:2)

    by mi ( 197448 )

    Small (without the Tk part), multi-platform, truly interpretive, and created to be embeddable. From John Ousterhout's introduction to his book [amazon.com] about his language:

    Tcl was born of frustration. In the early 1980s my students and I developed a number of interactive tools at the University of California at Berkeley, mostly for integrated circuit design, and we found ourselves spending a lot of time building bad command languages. Each tool needed to have a command language of some sort, but our main interest w

  • Until the 1.8 release the whole Ruby source code and libraries could be distributed on a 1.4MB floppy with room to spare. With 1.8 a lot of libraries have been added so it's about twice as big. (you can always leave out libraries you don't need to keep it light)

    Ruby is also easy to embed as well, but we decided to use swig to wrap our C++ classes so that they're accessable from Ruby and then script the whole thing in Ruby. This offers several advantages for our application since we wanted to allow users
  • I can't believe LISP wasn't suggested. LISP has one of the most simple syntaxes in the world to parse. A lisp program basically consists of a list of functions. (functionName arg1 arg2 arg3) .... (function) such that each arg is! you guessed it, a function. parsing is so easy a 4 year old could handle it. implement some of the more basic methods needed for a useful application and you are pretty much done.

  • Check out Ferite (Score:4, Informative)

    by FireChipmunk ( 447917 ) <chip@@@force-elite...com> on Wednesday January 07, 2004 @03:38AM (#7901204) Homepage
    Ferite [ferite.org] is a scripting language and engine all in one managable chunk. It is designed to be easily extended in terms of API, and to be used within other applications making them more configurable and useful to the end user. It has a syntax similiar to a number of other langauges but remains clean and it's own language.

    I love that it was designed from the Start to be Thread Safe and Embeded, unlike PHP or Python.
  • Now here is a good thing, the spammers can bombard us with junk about language extensions instead of extensions to a part of the male anatomy, which at the moment seems to constitute 90% of all spam.
  • The only extension I personally need is not for a language per se, but for a spreadsheet. I really need to be able to run something in a spreadsheet cell which will do text processing like awk, or sed, or maybe like something else entirely, which as you all know is orders of magnitude more powerful than the pathetic string handling that Bill has deemed to give us. I really need good user-defined functions (and no, VBA will not do the job!), and I even need the facility to split a row containing a cell with

Slashdot Top Deals

We are each entitled to our own opinion, but no one is entitled to his own facts. -- Patrick Moynihan

Close