Quest for the re-usable software grail

I’ve been reading Dreaming in Code and discussing project planning & management with my housemate. These topics have reminded me of the quest for “plugable,” re-usable software components. The quest has been ended for the most part for those who use Perl. The CPAN provides users of this particular language with a repository of code libraries (modules, in Perl parlance) which can be acquired, installed and applied with minimum fuss. The barrier to entry for getting your code into The CPAN is low to permit new ideas proposed by folks who don’t have the know-how to prepare and revise applications. This tends to cause some problems with regard to the signal-to-noise ratio, but I think it’s one of the primary reasons that the system is so successful.

In addition to this repository of code, which contains a great deal of duplicated effort, lots of modules intended only as prototypes, and pipe dreams which were never completed, third parties provide statistics about the robustness, applicability, and overall “kwalitee” of the code archived therein. As famously noted in Zen and the Art of Motorcycle Maintenance, “Quality” is a subjective concept and cannot be measured as such. “Kwalitee,” on the other hand, is “a set of formalities that tend to coincide with quality, according to consensus.”

There exist tools to analyze code for known problems which cause reduction in “kwalitee.” The action performed by such tools is often called “static analysis.” The sets of rules used in such systems to govern which parts of code are marked as somehow problematic are called “policies.” There can be different classes of policies, for example security, complexity, cosmetic. When developers write code keeping such policies in mind, they are said to be “using best practices.” It’s hard to keep every such policy in mind when building software, so static analysis tools were developed to help gently nudge contributors back to the narrow path.

Why am I mentioning all of this? Why should any more effort be put into building a system of re-usable software if The CPAN already exists and provides all of these tools? As much as I love Perl (and I do! :) ), it has a tendency to be used to fix all problems, even when it may not be the best approach. Sometimes you need to get closer to the processor than an interpreted language lets you. Sure, there’s always XS when you need to do that. But the barrier to entry is high. Another reason is that not everybody loves Perl as much as I do. Some folks want to use (for instance) C++. If the library is written in Perl, and your application is written in C++, you either need to embed a perl interpreter in your application or break your application into different processes and communicate between them. This complicates the application and such complications and prone to error.

So I guess what I’m trying to say here is that we need to take the lessons learned from The CPAN and apply them to a framework that all languages can interact with. In my experience, the most accessible language in terms of inter-language co-existence, the language most capable of getting close to the processor is C. All languages have a means by which they can re-use C libraries. The primary difficulty with C, though, is that it’s hard to get object orientation right with. It’s hard to create an object model that is flexible enough and consistent enough that interface bindings which feel “native” can be generated for every language.

Lucky for us, that hard work has already been performed by the folks at Sun, RedHat, Ximian and Novell. I’m referring, of course, to the GObject framework, the cornerstone of The GNOME Desktop and the Mono CLR.

So the next is a question for you, readers: What are your opinions about building a software repository intended to be “The CPAN of GObject modules”? Are there enough modules in existence to warrant the effort? Is the current system of distribution “good enough?” Is there a critical mass of people interested in using such a system?

Most importantly, is there anyone else out there interested in building this infrastructure? I’ve finally come to accept the fact that as much as I’d like to deny it, I just can’t do everything I want to in the time I’ve been allotted. This seems like a project that would do a lot of good for a lot of people, but it’s just too much for me to do by myself.

This entry was posted in CLI, compiler, Free Software, gtk+, language, mono, novell, perl, Software, test. Bookmark the permalink.

5 Responses to Quest for the re-usable software grail

  1. INightmare says:

    This is indeed a good idea. I was thinking about something like that myself. CPAN is indeed something that comes to mind when you think about ‘how go it would be if I could get that a piece of code for…’. It seems that PHP and Ruby communities have replicated that idea and it would be at least smart to build such collection of GObject pieces of code.

    And for starting such project… The beauty of FOSS development is that if you have a good idea, someone will certainly join you.

  2. Tak says:

    Yes! This is why Gtk+ is so prevalent among Free Software, regardless of language – it’s powerful, fast, and it works the same way in c, ruby, c#, python, ad nauseum.

    There have been many times when I’ve been looking for a library to perform some specific task to find that one exists in python when I need it for a ruby project, c++ when I need it for a c# project, etc.

    This is one of the things that appealed to me from the beginning about Vala – if I write a library in Vala, I get automatic accessibility from any language that will wrap gobjects.

    I would love to see a CPANlike repository of gobject-based modules.

  3. I would say: you don’t need to go back to C to get a base language. Vala is high level syntax with GObject code generation.

    But anyway, I wouldn’t concentrate in the low-level either. Why not helping Lluis with his ideas?: http://foodformonkeys.blogspot.com/2007/06/mono-gems.html

    Additionally, what I would say is that .NET needs a Perl on top of the DLR, in order to reuse all that old codebases and renew them with new possibilities. Why not starting IronPerl? I’d bet MS guys are interested in this idea (as well as they were with Python and Ruby).

  4. Hey all,

    Thanks for the feedback.

    Andrés,

    I’d love to see an IronPerl. When I interviewed for the DLR team in April of ’08, I brought it up with Shri, but Microsoft just doesn’t have the resources to implement Python, Ruby and Perl.

    I did a bit of work around it, and the most realistic thing to hope for is a managed perl6 :) If the gcc-cli project implements a libm, the existing C perl5 could start to be compiled down to IL, and we’d have something to work with, but would be a long time in coming.

    Tak,

    I’d never heard of Vala before. I read a bit about it, and it seems pretty neat. Generating GObject code seems like a pretty neat idea. You get best practices for free that way :)

    INightmare,

    Yes, it seems that everything is re-implementing the CPAN… I wonder if it would be good to do a language-neutral repository type system. Lots more thought needs to go into it. But to be realistic, the project needs to start small. :)

  5. Pingback: repository thoughts « The Pædantic Programmer

Leave a Reply