There are some libraries, which are available in their versions written in many different programming languages, like for example Lucene, which is written in Java (as they say, 100% pure Java), but has also its versions in C++, C, Perl, Ruby, Lisp and some other languages. And I'm talking about implementations in these languages, not just FFI interfaces.

Why do people do that? I can see one obvious reason: deployment and distribution (and probably development as well) easier when a project has fewer dependencies. But is there anything else? In what situations is it worth it?

  • 4
    It can be very expensive to communicate across the natural borders of your execution environment.
    – user1249
    May 25 '11 at 21:13
  • 1
    @Thor: Yet some languages/environments positively encourage crossing natural borders (C is a common example of this, and it's a strong theme among Tcl programmers). I suspect it relates mainly to memory (and occasionally other resource) management; it's really not good to have two memory managers in the same process, especially if they weren't designed to coexist. In the end, I suppose it comes down to what assumptions you make, and what operations they in turn make inadmissible… May 26 '11 at 0:31

Some reasons I've done it (rewrite C code in Haskell, in my case):

  • easier deployment: one build chain only
  • fewer dependencies (to gain more adoption)
  • more portable (e.g. to Windows) if the code is in a high level language
  • to add support for parallelism not easily done in low level C
  • to make the code a bit safer with its resoures
  • to make the code easier to trust
  • more idiomatic (strong types, simpler API, more reuse)

Typically reimplementing a library to be "native" to a particular platform allows for:

  • Simpler deployment and distribution
  • Easier debugging
  • More idiomatic APIs suitable for your exact platform
  • Often better performance (platform interop can be a pain)
  • Fixing design issues which are still in the original for compatibility

For example, I started the Noda Time project as a port of Joda Time. It simply isn't practical to use Joda Time directly from within .NET... you really don't want to have to spin up a JVM just to do date and time calculations, as well as working out how to do the interop between the two. An automated port (a la J#) might have been feasible, but the end result wouldn't have been a pleasant and idiomatic API to use from C#.


Some people do it to help learn a new language. They pick a lib they were familar with in a previous language, see that there is a need for it in the new, and begin porting it over.

Porting something familiar is the best way to focus on just the language parts of a new language, and not really worry about the problem domain.

It also has the added benefit of, once done, not being throw away code like so many sample projects found in a book or tutorial would be, it can actually be something the community can use, add on to, refactor, discusss, etc.


Sometimes you're developing for a platform where the tool the software was written in (Java in Lucene's case) isn't an option. If you want the features without having to reengineer the code from scratch, you port the code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.