Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Lightweight Scripting/Extension Languages?

Cliff posted more than 10 years ago | from the when-the-code-footprint-is-everything dept.

Programming 176

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?"

cancel ×

176 comments

Sorry! There are no comments related to the filter you selected.

Anything but odd/new language... (2, Insightful)

cymen (8178) | more than 10 years ago | (#7888919)

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.

Re:Anything but odd/new language... (2, Insightful)

awgriff279 (624548) | more than 10 years ago | (#7889148)

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... (2, Informative)

Anonymous Coward | more than 10 years ago | (#7889360)

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.

Why so many languages? (2, Interesting)

Futurepower(R) (558542) | more than 10 years ago | (#7889823)


"...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 seems that every self-motivated serious programmer writes at least one editor or one language or one compiler. Even I wrote a language and compiler -- for Hewlett-Packard data acquisition equipment.

I think Larry Wall didn't foresee the future when he started Perl. Did he begin Perl with the idea that it would eventually be object-oriented? Did he expect that he would spend his entire life developing his "report language"?

I'm tired of learning new languages. I don't see the point in it. I'll bet there are hundreds of thousands who learned Pascal in college who wish they had not wasted their time; except for Delphi, Pascal is dead.

For those who want an embedded scripting language, how about a C interpreter? Try Cint [root.cern.ch] or Ch [softintegration.com] .

EiC? (2, Informative)

Futurepower(R) (558542) | more than 10 years ago | (#7889842)

Or, how about EiC [linux-mag.com] , now hosted at Sourceforge [sourceforge.net] . "EiC is pointer safe."

Re:Why so many languages? (1)

smallpaul (65919) | more than 10 years ago | (#7892753)

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 was the most taught language. (1)

Futurepower(R) (558542) | more than 10 years ago | (#7893275)


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.

Re:Why so many languages? (1)

swagr (244747) | more than 10 years ago | (#7893638)

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.

Re:Anything but odd/new language... (1)

RevAaron (125240) | more than 10 years ago | (#7890970)

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.

Re:Anything but odd/new language... (1)

svanstrom (734343) | more than 10 years ago | (#7889746)

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.

Re:Anything but odd/new language... (1)

RevAaron (125240) | more than 10 years ago | (#7890928)

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.

Re:Anything but odd/new language... (2, Insightful)

JohnFluxx (413620) | more than 10 years ago | (#7889765)

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.

Re:Anything but odd/new language... (1)

arkanes (521690) | more than 10 years ago | (#7889861)

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. Blender? Temple of Elemental Evil?

And, of course, the rant just ignores the best reason of all - if you don't WANT to write your app in Python.

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

JohnFluxx (413620) | more than 10 years ago | (#7889949)

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.

Re:Anything but odd/new language... (1)

SilentStrike (547628) | more than 10 years ago | (#7890071)

" 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."

The difficulty from doing the mixed langauges thing doesn't come from smacking the intepretter binary somewhere, but rather from the bindings between the langauges. His argument is essentially that it is easier and more flexible to call C from Python, than Python from C.

"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. Blender? Temple of Elemental Evil? "

Extending Python doesn't mean the whole program must be in Python, it just means that the program flow has Python calling into C, rather than C callinng into Python. Extending doesn't mean that the performance critical portions must be written in Python. Essentially, when you write in Python first, and then replace the slow parts with C, you are more closely following the "premature optimization is the root of all evil" saying.

"And, of course, the rant just ignores the best reason of all - if you don't WANT to write your app in Python."

I agree here. The bottom line is it's a question of who is going to wear the pants. But if you do like Python, and are going to use it anyway, why not really take advantage of it? Relegate the lower-level langauges to things which need to run fast.

Re:Anything but odd/new language... (1)

boelthorn (711135) | more than 10 years ago | (#7892472)

Consider using Common Lisp as extension language. (For a more controversial aspect: Consider to write your program in Common Lisp) It has a ANSI standard, some very good compilers and all the things you want of a scripting language if you want to use it as such.

I have personally used ECL (Embeddable Common Lisp [sourceforge.net] ) to write a Common Lisp plugin [sourceforge.net] for X-Chat which works very well.

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

Christopher Cashell (2517) | more than 10 years ago | (#7894367)

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 uncommon language that you personally aren't familiar with, the fact that it's in use in the real world means that more people will be familiar with it, and that it will likely be a more stable and usable solution.

Creating a brand new language just for your application is a gauranteed way to annoy people because there is no chance that they will know the language before using your application.

Here are some possibilities, depending on what you're looking for:

Scheme/Lisp* based:
  • librep, used by Sawfish
  • Guile, the official GNU extension language
  • Elk, designed from the start as a small embeddable library
  • tinyscheme, another small implementation designed for embedded use
  • SIOD, a very small implementation that can be easily customized for your application
  • Kawa, a Scheme enivornment written in Java, that compiles Scheme code to java byte-codes, is an excellent choice for use in a Java application
  • Embeddable Common Lisp, while not as small or lightweight as most Scheme implementations, does a pretty decent job

For larger (and more common) languages, you can choose from:
  • JavaScript/ECMAScript, this is a great choice as it was designed to be used as an extension language, and there are at least a couple of free/open source implementations available. . . and it's use in web browsers/web pages has made it a very well known language
  • eperl, an embeddable form of Perl
  • Python, though not ideally setup for this, can be embedded in another program
  • tcl, tcl was designed parly for use as an embedded scripting language, and works fairly well in this regard

Some less well known, but still "real" languages that can make an excellent extension language include:
  • ficl, an implementation of Forth that's designed for embedded use
  • Lua, a language that was designed specifically to provide a small but powerful language for embedded use
  • S-Lang, a progammers library that provides a console GUI library and an extension language (used by jed, slrn, newt, mutt (optional), etc
  • cint, a C language style interpreter could probably be used easily enough
  • ch, another c interpreter
  • Bean Scripting Framework, BSF, is a great choice for java applications, as it provides a framework to use a numer of different languages, providing greater choice
  • Scriptix, an extension language with a C/C++ style syntax that evolved out of MUDix
  • ferite, an interpreter with "similiarities to perl, python, C, Java and pascal", and designed for embedded use
  • bsh, or BeanShell, is a small embeddable Java interpeter, written in Java, and has some extra "bonus" features of particular interest to scripters

* 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.

Guile (3, Informative)

crmartin (98227) | more than 10 years ago | (#7888926)

God knows the words "lightweight" and "Gnu" don't generally go together, but how about Guile [gnu.org] ?

Re:Guile (3, Funny)

aspjunkie (265714) | more than 10 years ago | (#7888966)

just Guile!? Don't forget Ryu [gnu.org] , Chun Li [gnu.org] , and Dhalsim [gnu.org] ! ;)

Re:Guile (0, Redundant)

crmartin (98227) | more than 10 years ago | (#7889050)

Uh, those links are broken.

Re:Guile (1)

Drantin (569921) | more than 10 years ago | (#7891437)

He was joking... look up the street fighter I/II etc characters...

Re:Guile (1)

crmartin (98227) | more than 10 years ago | (#7891924)

Oh. Okay.

What's "street fighter"?

Re:Guile (0)

Anonymous Coward | more than 10 years ago | (#7893025)

A very popular computer game from a few years ago. A 2D large-sprites beat-'em-up.

Was made into a really crappy film too, with Kylie Minogue (looking extremely hot) in it.

TinyTCL (3, Informative)

the_womble (580291) | more than 10 years ago | (#7888955)

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 (4, Informative)

Twylite (234238) | more than 10 years ago | (#7889058)

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 (4, Informative)

ianezz (31449) | more than 10 years ago | (#7889411)

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.

siod (1)

mschaef (31494) | more than 10 years ago | (#7889875)

I'd reccomend siod, or perhaps guile.

http://people.delphiforums.com/gjc/siod.html [delphiforums.com]

I've done a fair bit with siod lately, and can say that while it's not the most sophisticated scheme interpreter around, it dovetails very nicely with C code. It's trivial to write new functions, and defining new data types isn't that much more difficult at all.

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


For people looking for Lisp-style macros, siod includes a simple implementation of a feature that works very much like macros. If the symbol in the function spot of a list itself refers to a symbol, the referred to symbol's binding is evaluated as a macro rewriting function.

Oh, and as an example of its simplicity, the whole thing fits in something like 10,000 lines of code. That's garbage collection, a library of simple string functions, a Scheme evaluator, file I/O, and a bunch of stuff I'm probably forgetting...

IIRC, SCM and Guile are both derivations of the original siod code base. For that matter, so is STk, as it it itself based on SCM. Either of those would likely be a good choice too.

How much do you need? (2, Informative)

Ripsnorter (16359) | more than 10 years ago | (#7888998)

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 such a way that it is easy for scripting langs to get there hooks into. For example, on windows you can do this by providing com interfaces to all the things you want to have control over, then you can use any lang you want to control your app.

The need for "extension languages" (4, Insightful)

be-fan (61476) | more than 10 years ago | (#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: non-speed-critical apps written in C (0)

Anonymous Coward | more than 10 years ago | (#7889923)

Bah! When my app isn't speed critical, I make fun definitions like:

#define WAIT() do { } while( rand() % rand() )

Then I just sprinkle in a few WAIT()'s wherever my code runs too fast.

Re: non-speed-critical apps written in C (0)

Anonymous Coward | more than 10 years ago | (#7889952)

Yes, I'm aware that rand() can return 0.
Hint: I never said my code doesn't crash! :)

Re:The need for "extension languages" (2, Funny)

squiggleslash (241428) | more than 10 years ago | (#7890588)

Personally, I like C. And to be honest, I always thought the advantage in having a faster CPU was that my programs could run faster.

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7890858)

Personally, I like C.

Let me guess: you don't program for a living.

Re:The need for "extension languages" (1)

squiggleslash (241428) | more than 10 years ago | (#7891001)

I program for a living.

I think that's the difference between C and Python programmers - C programmers enjoy programming. Python programmers don't, at least everything my Python-loving collegues say suggests that the thing they like about it most is that they never get to understand what's going on under the hood.

Now, where Perl programmers stand is another issue. I think they're into cryptology...

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7891125)

at least everything my Python-loving collegues say suggests that the thing they like about it most is that they never get to understand what's going on under the hood.

Of course, C programmers don't understand what's going on "under the hood" either--otherwise, they wouldn't be programming in C. C gives you the impression that you are programming a PDP-11, which is nothing like modern hardware.

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7891884)

Er, only if you're programming a PDP-11 emulator. Or an actual PDP-11.

Would you care to explain what aspects of C force the hardware to resemble a PDP-11, or any other type of computer for that matter?

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7893270)

It's not exactly C, IMHO, but it is C-plus-Unix. Since programmers make these [faqs.org] sorts of "all-the-world's-a-VAX" assumptions depressingly often, hardware manufacturers are forced to cater to their idiocy, even if C itself doesn't technically require it, C-as-typically-programmed does.

Re:The need for "extension languages" (3, Insightful)

be-fan (61476) | more than 10 years ago | (#7893286)

C programs don't force hardware to resemble a PDP-11, but the C machine model doesn't resemble the actual hardware as much as C programmers like to believe.

- C is entirely serially, and the compiler has to infer paralellism from the code. Modern hardware is significantly parallel.

- C is entirely memory-based, while modern hardware does everything it can to avoid referencing memory.

- C has no primitives to describe branching, to aid things like speculative execution.

- C has no vector types, while most modern processors have vector units.

etc,etc,etc.

C has a very nice, simple machine model, but C programmers don't really understand what the computer is doing "under the hood."

Re:The need for "extension languages" (1)

bogado (25959) | more than 10 years ago | (#7893349)

Is there a programing language, higher then assemble off course, that do all the things you are stating? I am asking as curiosity, not to be anoying. I do love C, but I do think you are right.

Re:The need for "extension languages" (1)

be-fan (61476) | more than 10 years ago | (#7894044)

There are a few languages that do one or the other (APL, for example, has built-in vector types), but none that do all of them. My point was just that even with C, you're not really working "at the machine level" but still at a significant level of abstraction above it.

Re:The need for "extension languages" (1, Insightful)

kruntiform (664538) | more than 10 years ago | (#7893120)

I think that's the difference between C and Python programmers - C programmers enjoy programming.

That's crazy talk.

Python programmers don't, at least everything my Python-loving collegues say suggests that the thing they like about it most is that they never get to understand what's going on under the hood.

Supposing that you are not misrepresenting your Python-loving collegues, then yes, they are probably not good programmers (at least not great programmers). But so what? What have they got to do with anything? I don't even know these people. What about the Python programmers who do know what is going on under the hood (like me :D)? Are they bad programmers too? Really, if you are going to critique some technology, then please stick to technical issues. It's easy to make logically fallacious arguments: C programmers are bad because I know some C programmers that only know what goes on under the hood. They don't know anything else beyond that. And they smell. Therefor C is bad. (Note to any particularly dimwitted moderators out there: I don't believe that is an accurate representation of C programmers at all! I think it is quite untrue in fact. It is just an example of a logically fallacious argument used to illustrate a point. Please don't mod me down, you dipshit moderator!)

Re:The need for "extension languages" (1)

ajagci (737734) | more than 10 years ago | (#7891095)

Personally, I like C. And to be honest, I always thought the advantage in having a faster CPU was that my programs could run faster.

Yeah, so why do you program in C? C is not a good language for high-performance computing. With a lot of work, you can often get decent performance out of it, but C gets in the way rather than helping you.

Re:The need for "extension languages" (1)

squiggleslash (241428) | more than 10 years ago | (#7891260)

C is not a good language for high-performance computing.
C is a good language for high-performance computing, as are most third generation languages. I'm baffled as to why you'd think "C gets in the way", I think the thing my Python-loving friends hate most about it is that it doesn't. It does exactly what you ask it to.

Remember the context of this that lead to my original comment was the suggestion that people should ditch C and C++ for Python and Perl because some-how Python and Perl are "better". Python and Perl have their uses, but the notion that C and C++ are obsolete or that programmers wouldn't see advantages to writing quite substantial projects in either is utterly absurd.

I love C's simplicity. I love knowing what my code is going to do and being able to predict its strengths and weaknesses. I think well written C is, by itself, beautiful. Don't knock it, it's good stuff.

Re:The need for "extension languages" (1)

ajagci (737734) | more than 10 years ago | (#7892898)

C is a good language for high-performance computing, as are most third generation languages. I'm baffled as to why you'd think "C gets in the way",

Because C pointers don't help with writing faster code, but their existence in the language inhibits a lot of optimizations.

Remember the context of this that lead to my original comment was the suggestion that people should ditch C and C++ for Python and Perl because some-how Python and Perl are "better".

No, it suggested using high-level languages in general. Which high level language is better depends on the application. Python is probably better for most desktop apps. C# and O'CAML are better for general purpose programming. Fortran (modern versions) is better for high performance numerical computing.

I love C's simplicity.

C appears to be simple because it has few constructs, but its semantics are horrendously complex. Think about all the different things a pointer can point to and how those things behave differently as the program executes.

I love knowing what my code is going to do and being able to predict its strengths and weaknesses.

But you "can't predict what your code is going to do"--that is, in fact, one of C's biggest weaknesses. Any bug in any library or anywhere in your code means that all bets are off as to the behavior of the rest of the program. Unlike most other high-level languages, C and C++ provide no means of isolating errors and recovering from them reliably.

I think well written C is, by itself, beautiful. Don't knock it, it's good stuff.

C was "good stuff" in the days of bell bottoms, PDP-11s, and 64k i-spaces. Even then, 20 years after Lisp and Algol and 10 years after Simula, C was "good stuff" only in a sort of second-hand chic way--look how much I can do with this dirt cheap compiler.

Re:The need for "extension languages" (1)

squiggleslash (241428) | more than 10 years ago | (#7892969)

Because C pointers don't help with writing faster code, but their existence in the language inhibits a lot of optimizations.
Wrong on the first count, right in the second but the very need for optimizations should give you a clue to what my concern is about that.
Think about all the different things a pointer can point to and how those things behave differently as the program executes.
Ok, so we've gathered you're not particularly fond of pointers!
But you "can't predict what your code is going to do"--that is, in fact, one of C's biggest weaknesses. Any bug in any library or anywhere in your code means that all bets are off as to the behavior of the rest of the program. Unlike most other high-level languages, C and C++ provide no means of isolating errors and recovering from them reliably.
You're confusing two entirely seperate issues. Debugging is an entirely different issue to being able to predict the behaviour of code. Without knowing the underlying basis of the code, I cannot do the latter. If it's over optimized, if it uses hashing I have no control over, if it reads and writes without me having any idea what buffering, etc, is taking place beyond that supplied by the OS, I'm in no position to know how well my program will work.

Debugging can be fractionally easier in a 4G language, but that's not a substitute, or even the same ballpark, as being able to predict how a correctly written statement will execute.

C was "good stuff" in the days of bell bottoms, PDP-11s, and 64k i-spaces. Even then, 20 years after Lisp and Algol and 10 years after Simula, C was "good stuff" only in a sort of second-hand chic way--look how much I can do with this dirt cheap compiler.
Wow. So C isn't trendy enough. I get it now. Good grief.

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7893048)

No, c pointers don't help with writing faster code on a parallel architecture (if you are not on a parallel architecture, you are NOT DOING high performance computing). You're confusing high performance FOR YOU with real HPC.

Re:The need for "extension languages" (1)

squiggleslash (241428) | more than 10 years ago | (#7893080)

No, you're not reading the thread. Go look at this [slashdot.org] which is the first mention of "high performance computing" and clearly refers to my comment about faster CPUs.

You're not calling ajagci an subject-changing troll are you?

Re:The need for "extension languages" (1)

ajagci (737734) | more than 10 years ago | (#7893821)

No, you're not reading the thread. Go look at this which is the first mention of "high performance computing" and clearly refers to my comment about faster CPUs.

C is no good for "high performance computing", no matter which sense of the term you use. It isn't good for writing high performance desktop apps and it isn't good for writing high performance scientific apps (the more usual use of the term).

Re:The need for "extension languages" (1)

ajagci (737734) | more than 10 years ago | (#7893882)

Wrong on the first count, right in the second but the very need for optimizations should give you a clue to what my concern is about that.

I guarantee you that your C pointer code will be uniformly no better than Fortran array code.

And, no, I don't understand what "your concern" is about, other than holding on to a totally obsolete, unsafe programming language that you happen to know.

You're confusing two entirely seperate issues. Debugging is an entirely different issue to being able to predict the behaviour of code. Without knowing the underlying basis of the code, I cannot do the latter. [...] Debugging can be fractionally easier in a 4G language, but that's not a substitute, or even the same ballpark, as being able to predict how a correctly written statement will execute.

You don't even understand the problem. It's not about debugging, it's about fault isolation. C doesn't have any. Once your code or any library you call has as much as referenced one past the end of an array, the language guarantees absolutely nothing anymore. There isn't even any indication that anything has gone wrong.

You have gotten so used to C's misfeatures that you don't even understand that things could be different.

Wow. So C isn't trendy enough. I get it now. Good grief.

Yes, indeed, C isn't "trendy" enough in the same way gas lighting isn't trendy enough: it's dangerous and it's completely obsolete.

Re:The need for "extension languages" (1)

BRSloth (578824) | more than 10 years ago | (#7893784)

Because C pointers don't help with writing faster code, but their existence in the language inhibits a lot of optimizations.
C pointers are easy to understand if you understand the machine you are working in. If you don't (or don't care), then you can use a language that doesn't have pointers.

Also, optimizations are not a code problem. There are part of the project design. A well designed project will need no explicit code optimization, since the compiler will take care of it. And in my experience (I'm a coder for 16 years), compilers can do a better job optimizating your code than you.

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7892941)

C is not a good language for high-performance computing, as it lacks guaranteed referential transparency needed to enable vectorised parallelism. If that sentence means nothing to you, you're not really doing high performance computing (typically involving large parallel clusters), and you probably can't understand why people still use Fortran.

Admittedly, vendors of C compilers typically include language extensions ("restrict" et al.) to get around this, but C is not natively suited to high performance computing. High performance computing C code is orders of magnitude uglier than Fortran 95 code.

If you want a high-performance high level language, try a Common Lisp compiler or ML.

Re:The need for "extension languages" (1)

squiggleslash (241428) | more than 10 years ago | (#7893064)

If you want a high-performance high level language, try a Common Lisp compiler or ML.
Go back to reading the original context in which "high-performance computing" is used and you'll see it's a reply to a comment from me about faster CPUs meaning faster programs. The guy wasn't changing the subject, he was merely using fuzzy terminology.

Yeah, sure, I wouldn't necessarily program a Cray in C, but Fortran's not what I'd write a fast, standard, application in either.

Re:The need for "extension languages" (0)

Anonymous Coward | more than 10 years ago | (#7893181)

WTF is a "standard application"? A standard application in the high performance computing field will, even today, probably be in Fortran.

Google for "high performance computing". It's a standard term, and it _doesn't_ mean "x86 riceboy".

ML also consistently produces higher performance programs than C, BTW, since it can do more optimisation.

Most Common Lisp compilers also produce competitive performing programs with similar type inferencing techniques to ML, and Common Lisp has be-fan's originally stated advantage of implementation-language-being-the-scripting-langua ge.

Re:The need for "extension languages" (1)

be-fan (61476) | more than 10 years ago | (#7893081)

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.

Re:The need for "extension languages" (2, Interesting)

ajagci (737734) | more than 10 years ago | (#7891078)

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 concerns (probably unjustified, but still) about Microsoft patents.
  • Eiffel: open source compiler does not support separate compilation; some serious design flaws in its type system.
  • Modula-3, Oberon: not widely used.
  • O'CAML: great language but probably too complex and sophisticated for your average Linux hacker; lacks some facilities essential for high performance computing.

Overall, C# looks like the most promising to me: it combines the best features and simplicity of Java with most of the efficiency and C-interoperability of C++. Let's hope Mono will make it into all major Linux distributions soon.

Re:The need for "extension languages" (2, Insightful)

msuzio (3104) | more than 10 years ago | (#7891973)

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 mechanism should be simple, allow for ease of re-use (so the user community can exchange code snippets amongst themselves), and powerful enough to allow the sort of add-ons and control structures I (the app designer) *think* the user will need.

Perfect example is Neverwinter Nights (although the darn app always crashes on me... but I digress ). Powerful engine, with a scripting language bolted on. You would never try to write that application *in* the scripting language. You might ship a large amount of *content* with the app pre-written using the scripting language, though.

Re:The need for "extension languages" (2, Informative)

Webmonger (24302) | more than 10 years ago | (#7892573)

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 a problem

- The crashy code would still be in C/C++, but since the other code had been written more quickly, there would be more time to fix it.

The current issue [cuj.com] of the C/C++ Users Journal is all about mixed-language development.

Re:The need for "extension languages" (1)

be-fan (61476) | more than 10 years ago | (#7893228)

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.

Re:The need for "extension languages" (1)

Webmonger (24302) | more than 10 years ago | (#7894370)

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.

Re:The need for "extension languages" (1)

be-fan (61476) | more than 10 years ago | (#7894976)

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.

Dupe (0, Troll)

bromba (538300) | more than 10 years ago | (#7889045)

Gentlemen, this one is a dupe.
The question is: Was this ask slashdot submitted twice, or did the editor failed to remove it from submission queue last time?

Javascript! (5, Interesting)

Geek Boy (15178) | more than 10 years ago | (#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.

Re:Javascript! (5, Informative)

Anonymous Coward | more than 10 years ago | (#7889781)

Mozilla implementation of JavaScript in C is available at http://www.mozilla.org/js/ [mozilla.org] and pure Java implementation is at http://www.mozilla.org/rhino/ [mozilla.org]

And btw, ECMAScript/JavaScript can be pure functional as well.

Re:Javascript! (0, Troll)

Tablizer (95088) | more than 10 years ago | (#7893312)

I don't know if they improved it, but JavaScript had some of the worse string-handling abilities I have ever seen in a "scripting language". It lacked a Trim(), for example to clean out white space.

Re:Javascript! (0)

Just3Ws (687949) | more than 10 years ago | (#7893952)

See Mr.Crockford's website at

http://www.crockford.com [crockford.com]

for an excellent JavaScript extension library that you can use to add in functionality for string operations like trim() as well as many other functions ranging from 'nice to have' to 'my god this makes my life more better, thank you Mr.Crockford'.

s-lang (1)

noselasd (594905) | more than 10 years ago | (#7889094)

I find s-lang a very nice extension language. www.s-lang.org

ICI (3, Interesting)

tpv (155309) | more than 10 years ago | (#7889100)

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 (2, Informative)

glob (23034) | more than 10 years ago | (#7889151)

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.

Re:paxscript (1)

arkanes (521690) | more than 10 years ago | (#7892482)

For an open source alternative, look at Delphi Web Script [sourceforge.net]

REBOL (3, Informative)

the_greywolf (311406) | more than 10 years ago | (#7889237)

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 (3, Informative)

swdunlop (103066) | more than 10 years ago | (#7889763)

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?

Re:REBOL (1)

RevAaron (125240) | more than 10 years ago | (#7891018)

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. You only get an exe, not a DLL/so/dynlib/framework. For that, you have to shell out cash.

Developing for windows? (4, Informative)

KILNA (536949) | more than 10 years ago | (#7889278)

TinyPerl [sourceforge.net]

Object Forth? (4, Informative)

samjam (256347) | more than 10 years ago | (#7889356)

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

Re:Object Forth? (1)

tyrecius (232700) | more than 10 years ago | (#7891320)

What you mean is:

Forth is unlike most other languages. Also, it was designed (like LISP, every scripting language, and others) to avoid the debug, recompile cycle that is to common.

Re:Object Forth? (1)

Gnulix (534608) | more than 10 years ago | (#7892064)

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

In this case the word to use is "love", rather than "appreciate". Darn it, it's a lovely language!

How about JavaScript? (5, Informative)

Rich (9681) | more than 10 years ago | (#7889560)

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.

Re:How about JavaScript? (1)

arkanes (521690) | more than 10 years ago | (#7889836)

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)?

Re:How about JavaScript? (0)

Anonymous Coward | more than 10 years ago | (#7889929)

Sounds like you want COM. You might want to check the various Unix clones (XPCOM, KParts)

Re:How about JavaScript? (1)

Rich (9681) | more than 10 years ago | (#7890023)

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.

Re:How about JavaScript? (1)

arkanes (521690) | more than 10 years ago | (#7890355)

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.

Re:How about JavaScript? (0)

Anonymous Coward | more than 10 years ago | (#7893001)

Well, a de-facto standard "the C++ ABI" only recently came into existence on linux as gcc+intel+amd finally vaguely standardised it.

It's only in the past year or two that bridging to the C++ object model would be feasible on linux (n.b. windows has COM, which makes things easier), and even then, the C++ object system is so weak compared to, say, common lisp's, that it would be a poor fit.

Re:How about JavaScript? (1)

elflord (9269) | more than 10 years ago | (#7893854)

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

Sip makes it fairly easy to put python bindings on C++ without doing much in the way of "flattening" yourself. It's true that "flattening" needs to be done, but the tool (sip) takes care of it for you.

Re:How about JavaScript? (1)

Scaba (183684) | more than 10 years ago | (#7893880)

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

Re:How about JavaScript? (1)

smallpaul (65919) | more than 10 years ago | (#7892801)

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).

Copy of an advogato article (3, Informative)

DavidNWelton (142216) | more than 10 years ago | (#7889572)

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? (5, Insightful)

Anonymous Coward | more than 10 years ago | (#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.

Freedom Force (1)

IceFreak2000 (564869) | more than 10 years ago | (#7889766)

I know it's not directly relevant to the question, but FWIW the rather excellent Freedom Force [irrationalgames.com] uses Python as its scripting language [usyd.edu.au] .

Consider Ruby (3, Informative)

urbangipsy (301283) | more than 10 years ago | (#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

Depends on the host programming language and OS (2, Interesting)

angel'o'sphere (80593) | more than 10 years ago | (#7889996)

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

Io, Groovy (1)

alice_in_cipherland (727512) | more than 10 years ago | (#7890117)

Io [iolanguage.com] is a minimalist language.

If the app runs on JavaVM, then JavaVM-based languages (such as Jython and Groovy [codehaus.org] ) may be good choices, since the VM and its large set of libs are there anyway.

Re:Io, Groovy (1)

swdunlop (103066) | more than 10 years ago | (#7890935)

Io is wonderful, but I have had chronic problems with its garbage collection when writing complicated applications. Frankly, the GC system is incredibly buggy, and the coroutine implementation requires some very ugly manipulation of the C stack. Right now, for sophisticated, long running applications, the interpreter is just not mature enough. Give it a year or two..

Perl 4 (1)

duffbeer703 (177751) | more than 10 years ago | (#7890407)

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 (2, Informative)

truth_revealed (593493) | more than 10 years ago | (#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 (2, Informative)

schapman (703722) | more than 10 years ago | (#7892146)

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, my c++ code could handle all the collision detection/AI/proper sounds for things... it all comes down to good design. Something like lua is great for having somethign high level drive a low level engine.

Re:LUA (0)

Anonymous Coward | more than 10 years ago | (#7894190)

I'd like to second Lua.

It has been designed from the ground up to be a language to be embedded in to other applications.

It is very easy to write C or C++ functions and call them from within in Lua.

It is very easy to write Lua functions and call them from within C or C++.

It is small, functional and fun.

Nasal (2, Informative)

Nevyn (5505) | more than 10 years ago | (#7892273)

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.

Lua too big? Are you on crack? (0)

Anonymous Coward | more than 10 years ago | (#7895360)

Lua as a library is 60K on x86. Nasal is not much smaller - 45K. Lua can be smaller if you do not register some builtin functions. They are basically the same sizewise, but Lua interpreted code runs several times faster.

Has to be one that people already know (1)

Cardbox (165383) | more than 10 years ago | (#7893092)

Assuming that end users are going to be writing things in this language, you have to use one that there are already books/courses about, that their friends already know how to program in, etc.
This pretty much forces things like Javascript or VBScript, which may not be pretty but have the mindshare. You could use something more elegant and exotic, but will anyone bother to learn it? Will you be willing to support them when they haven't?
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?