Slashdot Mirror

With swig, you can write a C library and automatically use it from 17 different languages. It's cool that Rust is adding compatibility with Python, but they have a ways to go before they come anywhere close to the portability of C.

I'm looking forward to the Rust community adding these features.

Yes it is. Well-written C++ code will run on any platform, whereas even the best java code only runs on the java platform. This makes C++ much more suitable for cross platform development than java.

I have another way of looking at the same point........C is the most portable language, because if you write a library in C, it can be used from any language. Java, Python, TCL, Perl, Pascal, Fortran, C#, R, Javascript, D, Go, Ocaml, PHP, etc can all call into a C library (and a lot of the interfaces can be built automatically). If you write in Java, you're stuck building on top of it in Java.

http://www.swig.org/

Let me introduce you to a commonly used tool called SWIG, or the Simple Wrapper and Interface Generator.

I don't use COBOL because it doesn't have useful hooks into the libraries I need to use on a day to day basis. Same with Microsoft tech.

Microsoft development tech today is primarily:

1) .NET
2) C++

with heavy investments into both, balance being different depending on the kind of platform you're targeting (desktop/web/mobile). Also, JavaScript/HTML5 is coming as a third distinct platform with IE9, but we're looking at what is here and now.

So, I'm genuinely curious as to what libraries are you missing on either platform, especially keeping in mind the existence of C FFI on .NET (P/Invoke), automated wrappers to generate declarations for it wrapping C and C++ code (SWIG), and various MS and third-party tools facilitating cross-language interop, such as C++/CLI, IKVM for Java, IronPython, IronRuby, Phalanger (PHP on CLR) etc.

Or you could use SWIG it's already got C#/java, etc.. bindings.

The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently. - Nietzsche

SWIG makes it pretty bloody easy to wrap any C/C++ library for Python, or even Ruby, C#, Tcl, Perl, PHP et al.

http://www.swig.org/

Umm, because it's precisely the *right* language for the job. C++ restricts your binding options to other languages pretty dramatically, especially if you use parts of C++'s object model such as multiple inheritance.

Have you heard of Swig you Bulgarian sodomite?

If you can point me to a set of tools for the language you propose is squeezing fortran out that makes it as easy to work with vectors and matrices as Fortran, I would be thankful, but I haven't found it yet

SciPy makes it *much easier* to work with vectors and matrices in Python than Fortran. Besides vectors, it has a wide variety of scientific fucntions. F2Py lets you call your existing Fortran routines from a Python script. It even lets you access global common data from the Fortran program in a Python script. F2Py also lets you call routines compiled in C from Python. A similar program that lets you access C routines from Python is Swig

Using vectors and matrices in Fortran only seems easy to you because you are used to it, but once you get used to doing it in a modern language you'll realize what a mess Fortran is. Both Frotran and C suffer from the problem of handling variable-sized arrays, you have to allocate the arrays. In Fortran-77 and older versions you don't even have the option of dynamical memory allocation, you had to declare the dimension of the arrays at compile time.

With Python you have an almost perfect development environment for scientific computation. You get the fast development cycle of Python, with the quick execution time of Fortran or C. All that with a huge set of libraries and utilities for every conceivable need. Do you have data that you get from an external website, for instance? Python lets you automate the download. Need to get data from a database? Format the output into a PDF file? Create pretty graphics for a presentation? Save data to excel spreadsheets? Etc, etc? Python has libraries for all that.

There's another reason.

One /.er humorously said that this was because it wasn't not Java.

There's a grain of through there.

Obj-C as pointed by a /. isn't popular at all. Only NEXTSTEP and its various clones (Mac OS X, GnuStep) use it.
iPhone developers will have to learn yet another C variant, to which they are most probably not used. Some of those developer may even never learned C or C++ in the first place.

Java is the platform attracting the most mindshare currently for embed platform (keep in mind it was initially designed for it) and the MIDP platform you find on lot of embed device is quite efficient. Java is a popular language for programming embed software.
Python is also a very popular platform for fast development. Lots of developers are singing it praises (see xkcd for a caricature).
Perl and Ruby are other scripting language that have some momentum too.

All those language have way to use native C and C++ APIs. (SWIG is an example of tool to automate such C/C++-to-scripting-language-of-choice bridges)

Had Apple gone for a C/C++ SDK, they would made it available to C and C++ developers (both are maybe the world's most popular language, even if not the most high level or efficient) but also for Java developers (very popular on embed platforms), for Perl/Python/Ruby (hello young motivate university students) for C# and other .NET language (hello microsoft drooldrones) LISP (yes (that even means (support (for it (in emacs))))) etc.

By going for Obj-C Apple made their SDK available to Obj-C developers. All 2 of them.
(and the third one who's motivated enough to learn Obj-C).

Actually FOSS might have done language-interoperation in other ways: given that the source code is available, we might have had automated tools to generate bindings automatically

Actually, you should check out SWIG. It has been around since 1995... open source has had automated tools to generate bindings for a long time now. The main problem with this approach is that C does not give enough information. The biggest problem is memory management. most scripting languages are garbage collected, but there is not enough information in C headers for SWIG to know where memory is allocated, and so on.

Essentially, using SWIG comes down to letting SWIG wrap everything just from the headers, except you need to tell SWIG about memory management.... which functions allocate memory that should be garbage collected, which functions take ownership of memory so the object should be removed from garbage collection, and so on....

.net and mono are functionally equivalent to a SWIG wrapper - a bit easier to deal with, but similar nonetheless.

this is a bit different. for one, it allows you to redefine how an API is implemented. imagine a generic database API. instead of programming to a client library, all software can be written to a single standard API that then has its guts replaced with a simple call to be database specific. need to move from mysql to postgres and have 30-40 different maintenance programs and scripts that are programmed to deal with the API? simple, replace the guts of the API with the postgres API, and you're back in business. no need to write wrappers or even recompile.

has any syntax inspired more flamewars than python's?

You can do anything with it, from HTML parsing to a game physics engine to 3d graphics to Excel spreadsheets to... you name it.

Even if Python isn't quite enough for your needs, you can very easily link it with C language or Fortran modules in a trivial way.

If I have an alternative that is, at the same time, simpler and more powerful, then why should I bother with this whole Octave/Scilab/Matlab mess?

Pycaml is a Python binding for OCaml. From their website:

"If there's a native library you want to use that has a python wrapping, for very little extra cost, it can have an ocaml binding. This also means that ocaml code can import pure python modules and use them, making it ideal for using to implement test-case code on event processing systems. [Pycaml also] allows ocaml code to embed the python interpreter, define modules, classes, structures, etc."

If you want to use C and/or C++ libraries in OCaml, you can use SWIG. See SWIG's OCaml docs for details.

As for LDAP in particular, there's OcamLDAP. OCaml has many other native libraries. Check out the the OCaml Hump.

Pycaml is a Python binding for OCaml. From their website:

"If there's a native library you want to use that has a python wrapping, for very little extra cost, it can have an ocaml binding. This also means that ocaml code can import pure python modules and use them, making it ideal for using to implement test-case code on event processing systems. [Pycaml also] allows ocaml code to embed the python interpreter, define modules, classes, structures, etc."

If you want to use C and/or C++ libraries in OCaml, you can use SWIG. See SWIG's OCaml docs for details.

As for LDAP in particular, there's OcamLDAP. OCaml has many other native libraries. Check out the the OCaml Hump.

I mostly agree with you, except that I think FORTRAN needs to stay in the curriculum, at least in a survey course. Unfortunately there are a lot of science departments that use FORTRAN exclusively, because older professors have decades of code and no motivation to learn a new language. Until the next few generations of grad students can convince professors to use SWIG and Python (or something similar), a complete CS training requires at least a general knowledge of FORTRAN.

The OpenLaszlo compiler also has an ECMAScript parser, and it outputs Flash bytecode. The Legals Project will support the AMV3 runtime, which Adobe just made Open Source and Mozilla will be incorporated into Firefox.

Adobe open sourcing AVM3 and Firefox incorporating it is great news for OpenLaszlo, because it dovetails so nicely with the roadmap already in place!

Opening up AVM3 also enables the development of open source debuggers and integrated development environments like Eclipse, and makes it possible to embed an efficient JavaScript engine into any application, which has enormous long term benefits for everyone.

Please, I beg: somebody write an AVM2 back-end for SWIG! That would totally rock. It's an essential tool for wrapping libraries and extending languages, that SpiderMonkey's sorely missing.

-Don

From the OpenLaszlo Project Legals FAQ:

Q: What is the Legals project?

A: Legals is a project to extend OpenLaszlo to target multiple runtimes. For our initial release, we will be supporting AVM2 (Flash 7 and 8), AVM3 (Flash 9), and DHTML. It is also possible to extend legals to other runtimes in the future.

Absolutely: The Lua interpreter source code is very clean and well written, and wonderfully portable and platform agnostic.

Here's the source code that you can view online -- there isn't much to it! Four global header files, 19 core C files, 19 core header files, 10 library C files, 1 interpreter C file, and 2 compiler C files. Here is the main loop of the virtual machine -- notice that there are only 38 opcodes!

A great example of some interesting code written in Lua is the Auctioneer add-on for World of Warcraft (screenshots, manual). Here's the index of the Lua sources, and an interesing Lua file that calculates statistics on auction items. This code depends on features provided by the WOW client (implemented in C++ or whatever), as well as other Lua scripts loaded into the client.

One important reason to learn and consider using Lua, is that it's by far one of the fastest and smallest of all the interpreted scripting languages, on the Programming Language Shootout. It totally smokes most other scripting languages.

Here are the ratios of interpreted languages compared to compiled C code, in order of SPEED (the number is how many times slower it is than C, smaller is better unless you make your living by wasting time):
Lua: 6.4; Python: 7.4; Pike: 8.3; Tcl: 8.7; Perl: 9.0; Scheme MzScheme: 11; PHP: 13; Icon: 14; Smalltalk GST: 15; Ruby: 16; JavaScript SpiderMonkey: 32;

Here are the ratios of interpreted languages compared to compiled C code, in order of SIZE (the number is how many times bigger it is than C, smaller is better unless you make your living by selling memory):
Lua: 2.5; Haskell GHC: 2.8; SML MLton: 3.4; Python: 4.1; Perl: 4.3; Tcl: 5.1; Icon: 5.4; Ruby: 6.0; C# Mono: 6.3; Pike: 6.8; PHP: 7.1; Oberon-2 OO2C: 7.9; Erlang HiPE: 7.9; Java JDK -server: 9.1; Scheme MzScheme: 9.2; Mozart/Oz: 9.8; Scala: 10; Lisp SBCL: 10; Smalltalk GST: 13; Smalltalk VisualWorks: 15; JavaScript SpiderMonkey: 30;

Lua is even better than several compiled languages (like Java) when it comes to its size! Like Java, Lua also has a "just in time" compiler, but that was not used in these benchmarks (although I presume Java's was, because Java did very well with speed but not memory usage).

I think it's laughable that someone would put their time into learning a faddishly popular language like Ruby, but would then not consider learning a technically superior language like Lua, since Ruby scores so badly on these benchmarks compared to Lua, Lua has been around a lot longer than Ruby, and it had already proven itself in many commercial products (like WOW).

Lua really is far ahead of the pack of other languages in many ways, BECAUSE it's so clean and well designed. Plus its licensing terms are excellent, it's extremely portable, easy to embed and integrate with applications, and SWIG supports it well. So it's definitely well worth learning.

-Don

Yeah, I had a great fling with TCL/Tk, which was the best thing around in 1992, but I'm really glad it didn't become the Standard Scripting Language. As bad as it is, I can live with JavaScript.

But RMS was right when he said: If Tcl does become the "standard scripting language", users will curse it for years -- the way people curse Fortran, MSDOS, Unix shell syntax, and other de facto standards they feel stuck with. He forgot to mention Perl, and PHP was just being ill-conceived in 1994.

Of course the FSF was developing GUILE as an alternative to TCL/Tk. But Lua also has all the properties that Stallman recommends for an extension language: it's a real programming language for writing and maintaining substantial programs, with arrays, structures, numbers, semantically lisp-like, but with a traditional algebraic syntax, and extremely fast execution. And it's under the MIT license (ahem), so it gets used in real world commercial products (WOW).

But there are other important properties for a scripting language that he doesn't mention. Especially: Easy integration with C and native libraries, which is hard to get right in a Scheme system that efficiently supports full continuations. Easy integration with applications and libraries is essential!!!

The final straw that made me decide to use Lua instead of SpiderMonkey JavaScript, was that SWIG supports LUA well, but it doesn't support SpiderMonkey. That's very important to me, because by using SWIG instead of a language-specific binding (tolua++, boost, etc), SWIG makes it easy to plug my libraries into ANY scripting language (except JavaScript ;-).

-Don

Chicken Scheme is also quite nice. Compiles to C code, has a lot of libraries, and is supported by things like SWIG, so it's (relatively) easy to call functions written in C/C++.

Good languages are hard to design. Scriptable applications that dream up their own special-purpose scripting languages tend to have a lot of deep flaws and fundamental limitations. Most of the developer's resources go into the main application, not designing and supporting the scripting language. And special purposes non-standard languages usually don't have good development and debugging tools, either.

Python is a very well designed language, with a huge active community and robust collection of tools and extension modules, which was designed to be used as a general purpose application scripting language, from day one. Its syntax is quite simple, and there aren't a lot of exceptions to the rules (like Perl) or subtle nuances and inexplicable quirks (like PHP), so it's quite easy to learn.

One of the big upsides to using Python as an application scripting language is that all of the standard and add-on Python modules are at your disposal, and if you need to do anything specialized, you can write your own Python modules (using SWIG makes that quite easy).

Why would you want to plug your own custom Python modules into a scripable application like Maya? You might want to call libraries that import and export content, and integrate existing i/o and previewing code from the applications that consume the content you're building in Maya. And if your other applications are also scripted in Python, then you can use the same code and modules in your application and your tools, which really rocks! Python on Windows also has full support for OLE Automation, so you can easily integrate applications like Excel, and ActiveX controls, too.

But to stay on topic: Despite its crystal-meth-like popularity, PHP is an ameteurishly designed language, and has a long track record of each new version breaking compatibility by attempting to paper-machete over stupid mistakes of the past, that shouldn't have been made in the first place. But the difference between PHP and Perl, is that PHP is just naive, and didn't know it was making those mistakes. But Perl is totally malevolent, it chose to make all those mistakes on purpose, and it revels in its own fractal complexity.

Sure, go ahead with your experiment to arrange a shotgun marriage of PHP and Perl. But beware: this could happen to you!

-Don

You might want to consider writing a back-end for SWIG to support your language, which will make it easy to plug in new primitives and integrate libraries with your language. That will sure save you a lot of work, and enable developers to easily plug their own stuff in! SWIG lets you write interface definition wrappers for libraries (and can even use C++ header files directly, or you can tailor the interface by simplifying and modifying them with annotations), and SWIG automatically generates all the glue code for a wide range of languages, or pure xml that describes the interfaces for other tools to grok. There's an API for extending SWIG and writing new back-ends.

SWIG is brilliantly and practically designed, and deals well with harsh realities and nuances of C++. It totally rocks!

For a great example of a complex library exposed to scripting languages via SWIG, check out the Intel Open Source Computer Vision Library, which plugs into many scripting languages by describing its APIs to SWIG. If you wrote your own language back-end, you'd be able to SWIGify an OpenCV interface to your own language, as well as any other library that has a SWIG interface.

-Don

You might want to consider writing a back-end for SWIG to support your language, which will make it easy to plug in new primitives and integrate libraries with your language. That will sure save you a lot of work, and enable developers to easily plug their own stuff in! SWIG lets you write interface definition wrappers for libraries (and can even use C++ header files directly, or you can tailor the interface by simplifying and modifying them with annotations), and SWIG automatically generates all the glue code for a wide range of languages, or pure xml that describes the interfaces for other tools to grok. There's an API for extending SWIG and writing new back-ends.

SWIG is brilliantly and practically designed, and deals well with harsh realities and nuances of C++. It totally rocks!

For a great example of a complex library exposed to scripting languages via SWIG, check out the Intel Open Source Computer Vision Library, which plugs into many scripting languages by describing its APIs to SWIG. If you wrote your own language back-end, you'd be able to SWIGify an OpenCV interface to your own language, as well as any other library that has a SWIG interface.

-Don

This is probably a good place to mention SWIG: open source, mature - SWIG is an interface compiler that connects programs written in C and C++ with scripting languages such as Perl, Python, Ruby, and Tcl. It works by taking the declarations found in C/C++ header files and using them to generate the wrapper code that scripting languages need to access the underlying C/C++ code. In addition, SWIG provides a variety of customization features that let you tailor the wrapping process to suit your application.

From the FAQ:
Designed to work with existing C/C++ code. SWIG requires little, if any, modifications to existing code. For the most part, it encourages you to keep a clean separation between C/C++ and its scripting interface.

I haven't used it myself, but it sounds like it could help. At least you might be able to re-use your C++ code from Java.

I think it's lunacy to rewrite 6 years of code in a new language just for the sake of it.

I would agree too, rewriting everything in Java just means wasted time programming, wasted time debugging, and wasted time testing. Now, for me at least, the best solution is to do all future development in some managed, garbage collected language and use your existing C++ code from inside that language.

While directly using JNI or the Python C API is possible, the SWIG Project reads C++ headers and generates the neccissary code to use that from Java, Python, or many other languages. It works on Windows and UNIX. While it isn't 100% magic, it is about 92% magic with just a little bit of extra directives and stuff you need to tell SWIG about. For a huge project, the automation SWIG provides really makes it possible to use a huge C++ library from inside Java or Python (or Ruby, etc).

First, I'd like to ask how much memory you have available on the embedded system, and how many classes you are planning on using this introspection approach on. Do you have threads or processes on the embedded platform? Does your parameter tuning program have to run on multiple platforms?

If you have enough memory, you may want to embed something like lua, tcl, ruby, guile or python and wrap them in C++, then introspect those classes. I know this sounds like overkill, but it will seperate the dynamically changing classes from the rest of the program. As I'm sure you know, it is a pain to manipulate runtime state in C++. Pain will be eased by using SWIG

Do inherit from a class that has something like read_state() and write_state() in some format you can understand. Check boost - they may have something usable for you.

Also, think about whether it is strictly necessary to modify the various attributes on the fly with custom code. What I mean is, if you have a reload()/init() (better yet, the constructors themselves) method in your classes, you can have your GUI write out what amounts to a config file, and use the same interface to change parameters that you do to initialize the objects. This will help you keep your class invarients better.

Whatever you do, try not to let any of the UI muck get tangled in your embedded app. (For example, having your embedded app spit out html directly). Even if you have to write a seperate program to run on the embedded platform, that would be better than having your app communicate with your control program (be it a browser or native UI) directly. ( Unless your embedded app is already a web server :P )

It will almost certainly help you to use a command-line program (write it in some scripting language to save your time) as the first incarnation of the properties twiddler. Use a simple ascii protocol. This will be easy to convert to html later on. You will be happy to have your command line tool while you are debugging the browser interface.

If you have the ability to run a seperate program that just proxies your simple protocol to the web browser, so much the better. Thttpd is your friend here. It is one of the easiest HTTP servers programs to port to a limited platform.

eg. \n
class: foo
attrib: blarg=jack
attrib: sam=600
\n

A web interface has the following advantages:
- Easy to update/change the code
- Cross platform

If you haven't done any client UI stuff on windows or Linux, believe me, now is not the time to learn MFC or X11 or Qt or GTK+ etc etc. The only app I'd attempt with "native" widgets in that case would be with Tk.

Good luck!

P.S. The efficiency hits of all the above will almost certainly be worth it.

I've never been able to get the speed of OpenMCL-compiled code to compare the SBCL-compiled code. Every now and then I find myself switching back to SBCL for that reason, as I do some hacking in my free-time that is numerically intensive.

;; simple use of foreign-lambda*
 
(define yo
  (foreign-lambda* void ((int x))
  "printf(\"yo: %d\\n\", x);"))
 
(yo 33)
 
;; simple use with callback
 
(define-external (back) void
  (print "I'm back!"))
 
(define call
  (foreign-safe-lambda* void ()
  "back();"))
 
(call)

Was involved with a similar project but we were ripping out crappy Labview apps for a biological research company with lots of robots. Labview is initially easier but you get stuck after a while.

Tool selected was python

Boost Python (http://www.boost.org/libs/python/doc/) is a library for wrapping C++ libraries that already exist to make them accessible from Python. Includes the boost python library. A favorite for wrapping c++ code.

Swig (http://www.swig.org/) is another library for connecting C and C++
code with Python

ctypes http://starship.python.net/crew/theller/ctypes/
ctypes allows loading dlls/shared libs and calling functions in that lib.

PyInline (http://pyinline.sourceforge.net/) is a module which will allow
you to write methods inline in C.

Python can use COM or you can create COM objects. Make apps with simple web interfaces (Medusa) and webservices style interfaces. Also can check out jython etc.

6) When do I get to mix objects in PHP, Perl, C, and Java into a single codebase? PHP is my language of choice for most of my work, but sometimes I'd just LOVE to something in C to get some improved performance, or maybe take a perl class and access it directly from PHP... Since there's not a standards organization everybody pays any attention to, this kind of functionality just won't happen anytime soon...

see www.swig.org

php is a library that can be linked with a jvm using jni and both php and java can access the same swig-wrapped objects.

Sam

• C++
  • jEdit is a Java programmer's editor with excellent C++ support. I do development on Linux, Win32 and MacOS X, so it's very nice for me to have one editor I use on every platform. jEdit's not as featureful as, say, Emacs, but it's considerably more friendly to use.
  • Boost. If you're writing C++ and you're not using Boost, you're committing a crime against yourself.
  • Python. With Boost's Python library, it's easy to make your C++ applications scriptable. Write the heavy lifting parts in C++, then make those parts callable from Python. Do the rest of your development in a far safer, more sane language. You get almost all of the speed of C++, and far fewer headaches.
  • SWIG is another tool that's excellent for creating scriptable C++ applications.
  • Subversion for your version-control needs. Nothing else will do.
  • Doxygen for all your documentation needs. Learn it, love it. Your code's not done until every public part of the API has been doxygenated.
  • The GNU Autotools are really, really awful. They're also far better supported than Scons or pick-your-Autotools-replacement. Get ready to feel the pain of m4 macros. Sorry. :(
  • The GNU Compiler Collection started getting a good C++ compiler around version 3.0. I've been quite favorably impressed with 3.3, and I'm looking forward to 4.0. I don't recommend it for Windows, but for Solaris and x86 Linux it's beautiful.
  • I haven't found a good C++ unit testing framework yet. If you find one, please let me know.
• Java
  • Eclipse is an excellent Java IDE. jEdit also fits the bill nicely, if all you want is an editor. I use both frequently, and am quite pleased with both.
  • Subversion again for your version-control needs.
  • jUnit for unit tests. Your code's incomplete unless you've written unit tests for it.
  • Javadoc for documentation. I would recommend Doxygen, but it's quite possible you'll be deploying your applications on machines that don't have it installed.
  • Ant for all your build needs.

mycplusplus.i
%module mycplusplus
%feature("autodoc");
%include "mycplusplusheader.h"

and that is pretty much it. Most of the standard library is supported out of the box and you can easily include special case code. It even handles templates pretty well. Using their new fangled directors, we can even subclass C++ classes in python itself! It also supports java, guile, C#, ruby...

It is really an amazing piece of work.

mod the parent up!

Ruby isn't the fastest language on the block, but it's so easy to write C extensions for a Ruby program. Usually only about 10 to 20% of your code is speed critical, so this allows you to write that small part of your code which is speed critical in C while writing the rest of your code more quickly in Ruby. Oh and there's a profiling module that comes with Ruby that will help you figure out where your code is spending it's time.

I would also add that if you use Swig, it's quite easy to integrate your Ruby code with your C++ code. I tend to prototype in Ruby to get my design squared away, then I translate methods to C++ while all along using the same unit tests written in Ruby to make sure that everything is still functioning the way I intended.

I can't say enough good things about SWIG. It's an amazing piece of work that has saved me years of menial labor and enabled me to integrate all kinds of compex code into Python, from hairy C++ templates to third party Win32 libraries for which there is no source code. It works extremely well with Python, and many other languages too.

Here is the blurb from the web site www.swig.org:

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk and Ruby, however the list of supported languages also includes non-scripting languages such as C#, Common Lisp (Allegro CL), Java, Modula-3 and OCAML. Also several interpreted and compiled Scheme implementations (Chicken, Guile, MzScheme) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG may be freely used, distributed, and modified for commercial and non-commercial use.

-Don

I can't say enough good things about SWIG. It's an amazing piece of work that has saved me years of menial labor and enabled me to integrate all kinds of compex code into Python, from hairy C++ templates to third party Win32 libraries for which there is no source code. It works extremely well with Python, and many other languages too.

Here is the blurb from the web site www.swig.org:

SWIG is a software development tool that connects programs written in C and C++ with a variety of high-level programming languages. SWIG is primarily used with common scripting languages such as Perl, Python, Tcl/Tk and Ruby, however the list of supported languages also includes non-scripting languages such as C#, Common Lisp (Allegro CL), Java, Modula-3 and OCAML. Also several interpreted and compiled Scheme implementations (Chicken, Guile, MzScheme) are supported. SWIG is most commonly used to create high-level interpreted or compiled programming environments, user interfaces, and as a tool for testing and prototyping C/C++ software. SWIG can also export its parse tree in the form of XML and Lisp s-expressions. SWIG may be freely used, distributed, and modified for commercial and non-commercial use.

-Don

I have no clue what you mean by "solid system access" - but Perl has access to the syscalls directly on *nix, and there are ways to load Perl into the Kernel on Linux (though I think that is a bad idea).

I can't speak for Java; I haven't looked at how to do native access from Java.

You really should learn more about the systems you criticize before you start spouting about how impossible things are.

(Oh, and I like the idea of .NET - but mainly for the security control and having a standard VM come with the OS)

If you use Python, Perl, PHP, Ruby, or TCL chances are you use a multitude of libraries that would've been prohibitively laborious to wrap without SWIG.

wow that is awesome...I had no idea...I would like to clarify that the mission of CS courses at GT is to "teach concepts," not to "learn languages". Hence my first CS course (august of 1999...still have another year of my undergrad...I am lazy) being taught using only pseudo code. I learned the concepts, sure, but the class would have been a lot more fun had we been using Python.

At my job I work about half in C++ and half in Python...and it is a joy to use. I used to hate it and would only code in Perl...but those days are long gone. Perhaps perl6 will be better, but I find these days that I can't stand to touch perl code. Converting ~10 Perl files to python (Palm's Palm Emulator & Simulator come with a Perl interface, Keith was supposed to distribute my python version with all new Emulator versions buuuut....) was a huge pain due to perl's built-in obfuscation, not to mention its bad "global variable" habits... Python is still annoying in its lack of for (only having foreach, named for) and do loops, forced indentation (tabs vs spaces problem, non-deterministic if spacing gets messed up), and self being a required argument for every class method...but it's still amazing. Its interactive interpreter is probably the most useful application I have installed on my machine at work. Even when I'm on a C++ project I keep a python interpreter open to prototype and test code segments, convert between different display formats of numbers, generate utf-8 unicode strings, quickly start an interactive TCP socket server or client, do bitwise arithmetic, general math problems, generate test files on the fly, do data conversion....it's a programmer's best friend.

Python, with the help of its large standard library, makes writing applications incredibly fast. Last week I was assigned a small project which was to send large amounts of email for stress-testing purposes based on data found in XML files and inputs from the program's user. Nothing hard, but it involved xml parsing, speaking SMTP, Unicode, and a GUI. I recommended python, and it was done in 5 hours...with almost 2 hours of that spent on trying to figure out which smtp servers accepted what forms of Unicode encoding and how quirky they were about Content-types and charsets. Perhaps some ub3r-r33t C++ haX0r could do it in 5 hours in C++...but I'd be surprised. And, as always, if performance is a critical issue for some portion, writing a class in C++ and wrapping it as a python class with SWIG is about as painless as can be.

Perl isn't a terrible language, and it's spawned some great things (PCRE > *; also I tend to think PHP was inspired in large part by Perl and it's pretty awesome for web applications); I also admire Larry Wall a lot. But if you enjoy coding and haven't tried Python out yet, give it a shot.

I'm uncertain what you mean when you suggest that "the current state of O'Caml is that interfacing to these kinds of 3rd party libraries (using standard DLL or share library interfaces) is almost unworkable."

Are you referring to the ability to construct bindings for shared libraries written in C? Are you referring to being able to generate bindings to shared libraries written in C? Are you referring to being able to write short annotations for introducing symbols from shared libraries written in C in OCaml code?

I suppose one of the problems with being vague is that people have no idea what you're asking.

You can write bindings to C libraries by hand using the FFI, like you can with Python, Perl, or Java.

There are ways of generating wrapper code for interfacing to shared libraries, like CamlIDL and SWIG. You could also generate interfaces for use with the Dl module.

The Caml Humps site is a good place to start looking for some of the presently available libraries.

I think a far more annoying aspect of Objective Caml is that it is not currently possible to have natively-compiled dynamic shared libraries written in Objective Caml; all programs will be statically linked to Objective Caml libraries. You can load dynamic bytecode, but that's really just not the same.
There once was a program for wrapping Objective Caml code into a DLL but I don't think it has been kept up to date, it's a dirty approach, and as far as I recall it only worked on Windows.
There's the SCaml effort, but it seems to be falling behind, is incomplete, and only works on a few platforms.

Because it's very easy to expose a C api to practically any language in existence

Absolutely.

but very difficult to expose a C++ one to anything except C++, and in fact it's generally done by flattening the API to a C one

Are you sure that's still true? It was true the last time I checked, but doing a look around today, it seems that SWIG has become very good at wrapping C++ in anything from C# to Tcl.

The author mentions doing something like you did (reading the raw code directly from the serial port) and then was forced to switch to USB mice because the serial ones are pretty much impossible to find now.

No bindings for python, but those shouldn't be too difficult to write... swig maybe?

swig

I have found that using those slow languages and a nice swig of low level goodness after performance tuning to be a very powerful combination. I try to get the problem correct first and optimize as needed.

For medium- to large-scale scientific computing, I've found that a mixture of Python and C/C++ gets me the right combination of speed and flexibility. I write the main number-crunching pieces of my code as objects in C/C++, then use SWIG to generate the wrappers necessary to interface my objects with Python. The control structures are all in Python, which is where I really want the flexibility.

SWIG can be useful also.

Since I believe in Ousterhout's dichotomy, my favorite code generator is SWIG. It automatically create bindings for calling C and C++ libraries from scripting languages like Python, Lua, Perl, Ruby, PHP, and Tcl.

This was a very interesting article. I natively speak Perl, C, and C++, know enough about PHP to get by, and still remember some Commodore 64 BASIC (10 ? CHR$(147)). I am also, as I believe I've said before, not afraid to learn things like Java, Python, Ruby, maybe even Visual Basic again (God forbid) should they prove exceedingly relevant to my case - in fact, I quite look forward to knowing (hopefully) all of them and then some. But never Pascal. (Just kidding.)

I've really found that the thing I hate most about programming in general is that no single language is the right one to use for any of my programs! I am very interested in any effort I ever come across to do functional merging of disparate environments. In addition to a couple of workarounds I've invented in the past for shoehorning Perl into PHP, I like reading about things like SWIG, the open CLR, and even COM (the concept more than the implementation), and a smile always comes to my face when I think about the Inline library written for Perl.

Now, the thing I really pine for is all of this interlanguage binding stuff being easy, fairly portable, more synactically simple, and less hacky. I know that these exist, but not quite completely together. If I write a program in Perl with use Inline C, I can never be sure that anyone else has all the development tools necessary to compile all the C on the fly. Writing a program in Visual Basic with a nice mouse-drawn GUI and an external component is really easy - but it's Visual Basic. Writing a component wrapper for Perl is fairly straightforward with SWIG, but some well-thought-out language features would make it easier. And COM... I'm going to have to try wrapping my head around that book again someday... I'm sure the ATL makes it all very simple, but can I use ATL from MinGW? From C? From Perl? And don't try to tell me that I need to learn yet another flavor of XML to make all of this work.

That's mis tus centavos.

(Note: I disclaim perfection. Don't hit me too hard; I admit I haven't done enough of my homework to claim this post isn't full of holes. Once I've looked this whole matter through, if ever, and if I still haven't come up with anything good, I may just have to take a deep breath, lay down a syntax, figure out how to use a lexer generator and a compiler compiler, and throw together some ghastly but very easy-to-use homogeneous aggregator system. Either that, or I wait for Parrot to interoperate with Mono...)

I'm reckoning that I aught to learn a language that sits in the middle.

Now that's a good instinct. You definitely ought to be looking for something to help there.

Is TCL a good option here? Or would I be better with Python or Perl. (Ruby's out - don't know anyone to ask stupid questions about Ruby to).

Long-standing arguments between language fanatics notwithstanding, you should choose whichever of the languages suits your own personal style best. After all, it's not all that hard to quickly try all of them and all of them can do the "code integration" thing. I know that the Tcl community is virtually always welcoming towards newcomers, and many people find that to be a big plus, but one of the things we always recommend is that people choose something that suits them. After all, they're the ones putting the effort in to learn something new.

If you decide that you want to progress from calling your C and C++ code as external programs to integrating it into your scripting lanugage, you should probably look at SWIG as your first step to getting the wrapper code; it doesn't do as neat a job as hand-written stuff, but it is a much quicker way to get something working.

Hear, hear...

Far too many of the 'anti-tcl' element have no experience whatsoever with the language.
I've been using it for some years now on quite a few large(-ish) projects, and sure, it has it's drawbacks (typing, anyone?), but the advantages more than make up for it.
Any performance (speed)-critical bits get done in C or something, and the 'glue' and GUI are Tcl/TK.
Also, the ease with which extensions can be built and added (Think SWIG!) helps a lot.

Since everyone's so anti-, here's my Anti-Perl link for the day: (flame away!!)

Here..

Ugh! call that a language??

Ah good, someone got in before me :) It is definatly a good idea to separate out the GUI part when dealing with cross-platform applications, since a lot of portability problems reside there.

In all honesty, I don't recommand Qt or wxWindows - they are great toolkits, but you lose out heavily on productivity compared to visual development environments with GUI builders. While both of these have associated builder tools, I don't consider them very mature of capable compared to VB or Delphi/C Builder. There is also a write-once-debug-and-tweak-everywhere concern (just getting wxWindows looking good on Windows and Solaris takes some effort).

Java is a great choice as it is supported on many platforms, has powerful GUI classes, a couple of builder products, and has several means for client/server support, including CORBA. But for UI applications it isn't hugely productive (strangely enough).

Some of your other options include ParaGUI and SDL, gTk, GraphApp, V, Mozilla's XPToolkit and XUL, and WideStudio.

I have grappled with exactly this question (legacy C/C++ needing to go cross platform with GUIs), and the best answer I've come up with so far is to keep your main code in C/C++ (since you have the legacy code AND the skills), define a clear UI abstraction layer, and create the UI in a scripting language such as Tcl or Python. Use SWIG to tie the script to native C functions.

I have more experience with Tcl/Tk, and believe it is more widely portable (especially the GUI consistency), but it is slower and arguably more difficult to program than Python. Still, this depends on what skills you can acquire, and what your UI requirements are.

Prechelt has an empirical comparison of some languages, including C/C++, Python, Tcl and Perl, and most importantly he has productivity figures! Keith Waclena has a Language Crisis page of comparisons, and Doug Bagley hosts the Great Computer Language Shootout. There are all invaluable resources for determining a balance between portability, functionality and productivity.

So the first reason for "plan first, then code" is that coding is expensive. That expense represents a risk if you're pursuing an approach that doesn't work out. Throwing away a plan is quicker and less expensive.

The second reason for "plan first, then code" is that a written plan is a clear expression of the ideas in the plan. Code is often not very readable or very obvious, and a large body of code may require weeks or months of study to get all the nuances at work.

There is a hidden disadvantage to "plan first, then code". Remember that we're trying to manage the risk of choosing a dead-end approach, so we want to minimize the investment before the discovery that the approach is bogus. A non-executable plan won't catch all the design bugs. It will only catch the design bugs that you can recognize on inspection of a written plan; the screening process is limited by your own human cognitive faculties.

What if we could write an executable plan, in a language that is clear and expressive, and in which writing the plan is inexpensive? This would be the best of all possible worlds! Luckily you're not the first person to face a daunting software design challenge, and people have been designing languages for exactly these constraints for many years (Python, Perl, Scheme, Ruby, Smalltalk, and others. These languages vary in the expressiveness of their syntax. If you're concerned about the mental expense of coding, you probably will want to avoid Perl (which looks a lot like C) and Scheme (which requires a mental paradigm shift). My off-the-cuff recommendation among these would be Python.

Why not write your final product in one of these easy, inexpensive, readable, expressive languages? Alas, many of them don't have the performance of C or C++. If you're doing something computation-intensive, that matters. But wait! There is another saving grace, called SWIG, a program that lets you glue small bits of C or C++ code into your larger program written in one of the easy languages.

In most computer programs, the performance is gated by a small number of small pieces of the code. Usually, the majority of the code does not have a big impact on performance. If you can identify those small performance-expensive bits, and translate them to C or C++ and glue them back into your program, you get the speed you want, and 95% of your code is still readable and expressive, and easy to change later. The trick to finding these performance-limiting bits is called profiling (see 1, 2, 3).

So here's the advice (assuming Python):
1. Spend a day learning Python, two days if you're busy. Python has lots of great libraries, skim the list of libraries as somebody may have contributed something you'll need.
2. Write your entire program readably in Python. Don't worry about speed yet. Rewrite as required until you're sure you've got a good design.
3. Use profiling to locate the few small pieces that slow down your program.
4. Use SWIG and C/C++ to rewrite those pieces and connect them back into your program.