Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer

Truly reusable software components

by vrk (Chaplain)
on Oct 17, 2007 at 17:04 UTC ( #645508=perlmeditation: print w/replies, xml ) Need Help??

Perl programmers have CPAN. It's a repository of modules for all sorts of problems and solutions, interfacing with various technologies, network protocols, and file formats, adding features to the language, and a very long list of other ready components. In a way, it fulfills the dream of object-oriented programming people, and really any programmer, of having a generic and complete library of all written modules so far that can then be used in solving new problems.

This is an ideal situation. How many Perl progammers realize it? It's not only about saving time and effort, or enabling you to use technologies that you don't have time or interest to learn, or the ability to create well-nigh trivial solutions with just the right choice of modules, or having the largest repository of modules to brag about. It's all this and a realization of an old ideal. With sugar on top.

There's only one problem with it: it's Perl only.

Other programming languages do have "comprehensive archive networks" -- frequently modelled after CPAN itself (which, in turn, was modelled after CTAN). With some googling, I was able to locate the following archives of reusable modules for different programming languages:

Network Archived technology Year founded Approximate size (Oct 17th, 2007)
CTAN TeX 1992 7.5 GB (probably including different versions)
CPAN Perl. Of course. 1994 4 GB, 12345 modules
CRAN R 2004? 1197 packages
CEAN Erlang 2006? 212 packages
CKAN Open Knowledge Definition 2005 112 packages
JSAN JavaScript 2005 A few dozen?
CSAN Scheme 2004 0 packages(?)
cCLan Lisp Some time after 2000? ?
PLaneT Scheme ? Around 270 packages
ASDF-Install Lisp ? Around 360 packages

(Well, Open Knowledge Definition is not a programming language. TeX is, in a way. Is it Turing complete?)

The main problem is duplication of effort, something these archives try, by definition, to reduce! But there doesn't seem to way a out of the dilemma: how do we create a repository of generic, truly reusable software modules that are language-agnostic? There is no inclination of the world converging to one single programming language, so picking one "universal" programming language is not an option.

Perhaps there could be an archive targeting a universal virtual machine. Although there would have to be consensus on the machine architecture first (I propose the SECD machine), imagine that all programming languages had compilers that could target the virtual machine. The packages in this imaginary archive would have two versions: the source code and binary machine code for the virtual machine. Then, depending on if you have the compiler, or the language runtime environment, installed or not, an automatic install tool would pick either the source code of the program or the binary version compiled to the virtual machine.

Benefits: as long as source languages had compilers, modules could be written in any language, in principle. Even if you had never heard of the language before, you could still use the virtual machine code bundled with the module.

The obvious drawbacks are having to rely on machine language again, even if it is for a virtual machine. Another is the complexity involved, and duplication of effort in terms of compilers.

Any other ideas? I don't really accept "but Perl is a universal language!" as an answer, at least not until Perl 6 exists.

Update: omouse pointed out more Scheme and Common Lisp archives, which were added to the table: PlaneT and ASDF-Install. The latter seems to even be hosted at CLiki, which is where cCLan can be found too... Sorry for the oversight.

print "Just Another Perl Adept\n";

Replies are listed 'Best First'.
Re: Truly reusable software components
by moritz (Cardinal) on Oct 17, 2007 at 17:23 UTC
    The idea of a common virtual machine is used for .NET, and, more popular here, parrot ;-).

    The big difference is that .NET is optimized for statically typed languages, and parrot for "dynamic" languages.

    The parrot developers are working hard on implementing all kinds of languages, and once they have released version 1.0 I'm sure they will gain much more interest. Especially if they manage to make it very fast. I believe they will ;-)

    That will make sharing of libraries much easier, so you'll be able to code in "Perl 6 on Rails" if you want, or Python with Catalyst - fill in your favorite language and library.

    The big problem, as always, is to convince enough people to focus on one platform (be it a VM or something else).

      I certainly will dictate all my projects to use .NET VM if we ever go that way. I won't rely anything that's all volunteer effort.

      There is a counter-open-source movement nowadays for reasons.

        Don't feed the troll  <*())))><
        Interesting take on things. You would prefer to rely on a project that can be killed by a single person's decision (non-volunteer) vs. a project that has 100k people who could take it over and keep it up and running. Interesting ...

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
        There is a counter-open-source movement nowadays for reasons.

        And those alleged reasons are...? All I've seen from you here are attempts to shoot down the claimed advantages of FOSS. I've not seen a single claim for why proprietary is better. Based on the arguments presented here, it would appear that you're claiming proprietary is, at best, no worse than FOSS.

        As for my own experience, I was working on a DCOM-based project back in 1998 or so. I finished it, the company shipped it, and the support group then started getting a steady stream of calls from customers who were having problems with components not being able to talk to each other. After much investigation, we ended up with a semi-official response of "well, try reinstalling - that usually convinces DCOM to start working again." This was still going on when I left the company several months later.

        You've asserted that technology changes by the vendor don't count because you'll be rewriting in 5 years anyhow (a dubious assertion, given how much of the world runs on software well over 5 years old), but this wasn't a change by the vendor. It was a component which the vendor hyped rather heavily, but simply didn't work reliably. Were we able to fix it - or even to investigate the cause so we could develop a workaround - ourselves? No. Did we have a snowball's chance in hell of getting Microsoft to fix it for us, whether we paid them or not? No.

        That is when (and why) I made the decision to distance myself from closed-source technologies. I've been much happier since then.

Re: Truly reusable software components
by kyle (Abbot) on Oct 17, 2007 at 17:21 UTC

    Well, Open Knowledge Definition is not a programming language. TeX is, in a way. Is it Turing complete?

    Yes, for what it's worth, TeX is Turing complete.

Re: Truly reusable software components
by bradenshep (Beadle) on Oct 17, 2007 at 18:35 UTC
    While it's by no means a universal VM, or even a VM, x86 32-bit architectures fulfill some of this, in the sense that it's commonly and widely used.

    With a more general and uniform way of calling libraries written in other languages from any of the languages (see .NET) the virtual machine and the machine itself can be one and the same. Give every language a compiler for the native architecture (or an interpreter running natively on same) and it's your VM.

    The "general and uniform way of calling libraries written in other languages" is the tricky part.
Re: Truly reusable software components
by doom (Deacon) on Oct 20, 2007 at 19:02 UTC
    The main problem is duplication of effort, something these archives try, by definition, to reduce! But there doesn't seem to way a out of the dilemma: how do we create a repository of generic, truly reusable software modules that are language-agnostic? There is no inclination of the world converging to one single programming language, so picking one "universal" programming language is not an option.
    Writing code for a VM isn't a solution, because in general the real problem here is not solvable by technical means: it's fundamentally a social problem.

    Groups of programmer's are uncomfortable using tools that are not written in their language of choice. This is for a combination of reasons ranging from mindless snobbery to intelligent conservation of effort.

    This subject also comes up when discussing extension languages for programmer's development environments. To quote what I've said before on the emacswiki, ExtensionLanguageAdvocacy: "But embracing multiple languages necessarily involves sub-dividing the community. Even if there’s no actual fork in the elisp code-base, there would be splits in the emacs community – you need to be a perl programmer to further extend an extension written in perl, and conversely most perl-programmer’s will have little interest in assisting with work on extensions written in Java."

Re: Truly reusable software components
by omouse (Initiate) on Oct 19, 2007 at 22:00 UTC
Re: Truly reusable software components
by Cop on Oct 18, 2007 at 00:15 UTC

    Programming is art and a way to express oneself, so there will always be many VM's, not one.

      How does the VM affect the way you express yourself?

      There will of course be many VMs, but I don't think you have the reasons right. There have to be several because the languages are conceptually different and thus a common VM would either be too slow, low level or complex (try to imagine a VM that works well for static-typed imperative languages, dynamic-typed imperative languages, strict impure functional languages with their advanced type sytems, pure lazy functional languages and Prolog type languages. I can't.

      Another reason is historical ... it takes a lot of work to change the VM, even if to the users of the languages it would be completely transparent (and would not in the least bit affect their ways to expressthemselves or their artistic freedom).

      Yet another is psychological. "We think we can do better." Which might even be true especially if the language is far enough from what the authors of the other VMs expected.

        You didn't get my angle... True, VM still allows me to express myself, VM or not, doesn't impact... However my angle was: There will be lots of people who want to express themselves by creating their own VM's. They will gather and move ahead like parrot guys.

        The whole IT history was like this...

        One more angle...On the other hand, there will be new technology to replace VM, if VM ever becomes a real trend. The IT world has been ever changing.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://645508]
Approved by moritz
Front-paged by moritz
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others taking refuge in the Monastery: (5)
As of 2018-06-23 03:05 GMT
Find Nodes?
    Voting Booth?
    Should cpanminus be part of the standard Perl release?

    Results (125 votes). Check out past polls.