Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

migrated from stackoverflow.com May 25 '11 at 20:10

This question came from our site for professional and enthusiast programmers.

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… –  Donal Fellows May 26 '11 at 0:31
add comment

4 Answers 4

up vote 11 down vote accepted

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)
share|improve this answer
    
These are really good reasons. Thank you! –  m01 May 27 '11 at 8:43
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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