Lambda the Ultimate

"most importantly form a practical point of view, these days, it makes distribution by source easier, since required modules will be fetched automatically."

This is 99% of the reason I wrote PLaneT in the first place. People were always making little PLT scripts for various tasks, but there was no good mechanism for sharing them: you can download and install somebody's .plt file for your own use, but your users will have to install the same libraries to be able to get your program working; if you think they'll object to having to install 80 libraries just to get your Pokemon card sorter working you're just going to do without the libraries. This happened over and over again, to the point where it was folk wisdom that every serious PLTer had built their own redundant library for every possible task, and that's no good for anybody. I figured an automatic installer was a workable answer.

As for why it's incorporated directly into the language rather than being an app that goes on the side: it tied in perfectly with the already-existing require form, it made usage much easier (ease of use was our #1 design priority), and nobody to my knowledge had done it before, so I wanted to try it out and see what'd happen.

PLaneT hasn't been out long enough for me to tell you whether that turned out to be a good idea or a bad one. I can tell you that we've found it great for distributing libraries but less great for distributing more application-like pieces of software; that's been the biggest problem we've run into so far.

Oh, it's cool alright. Else I wouldn't have linked to it, would I? :-)

My question was of a more general nature. Should other languages and module systems attempt to solve this issue (thus havving to deal perhaps with things like versioning, security, network access etc. etc.) or should this sort of thing be left outisde the scope of language design?

Only the most recent version is listed on the page, though. For instance, Neil Van Dyke's webscraperhelper.plt has a version 1.0 and a version 1.1 available (those are PLaneT package version numbers, not library version numbers, so they follow a very consistent pattern, and if there's a 1.1 you can be sure a 1.0 exists as well).

The way the module system works is that if you say (require [whatever]), that [whatever] gets shipped off to an ordinary scheme function called current-module-name-resolver that turns it into a lower-level thing and handles namespace-attach-module issues. PLaneT works by having an entry in the default current-module-name-resolver, and users are free to override that function entirely to do whatever they want.

However, if you write all your Scheme code in modules (as PLT hopes you will!), you find a problem: by the time the code that overrides the default module-name-resolver gets executed, all the requires are already done, so you can't really install a new resolver usefully (at least not within the context of a module). That's why PLaneT had to be built in to the interpreter rather than just being a pure user library.

Language size and library size and/or module distribution seem pretty orthogonal to me -- witness asdf-install for Common Lisp, a module distribution system for a large language (or small language with large very-standard library, depending on how you want to slice it) with multiple implementations.

I'm not sure those categories are exhaustive, but I think one of the things we've learned about programming languages in the past several years is that for practical use, having access to large libraries is more important than the expressiveness of the underlying language. For instance, a lot of people choose to program in Java even when they like OCaml or something better just because of Java's high-quality standard library. And of course CPAN is widely touted as one of Perl's best features.

I think academic-types tend to sort-of recognize that, but since it doesn't feel like an academic problem, they dismiss it and work on problems that are more likely to lead to publication and that incidentally might help real programmers. That may just be a fundamental divide between academic language design and commercial language design, but I'd like to think that at least those of us on the academic side can put some kind of thought into how a language can best facilitate libraries. Having a big standard library (python, java, Common Lisp) is one way to go; automatic distribution (perl, Common Lisp's asdf-install, PLT) is another. But all these attempts are just stabs at something that seems like it might work; and they all do work, though it's not clear which ones are better or even what the relevant dimensions of comparison are. To my knowledge nobody's done a really thoughtful study of the subject.

Nobody outside academia cares about static expressivity, because they don't see the value in it.

Gee, Frank, that sounds an awful lot like resigning the game to the "pragamatists".

You feeling OK? ;-)

I did not say there was no value in it, only that its value is largely unrecognized.

I didn't think you were saying there was no value in it, just that you were giving up the fight, leaving the benighted non-academics to their fate.

For me the ongoing challenge is to find ways to make advanced PL concepts usable and relevant for practical applications. Algrithmic complexity and theorem-proving may not be in big demand, but modularity, readability of code and cooperative coding are.

Making a "sales pitch" based on these factors just might make inroads...

This is certainly what drives me. It makes me nuts that folks in academia who are striving to to improve the state of the art in software development are dismissed as ivory tower theoreticians while the "real world" is stuck with C++, Java, C#, Visual Basic... more days than not, I get up in the morning to sling C++ and ask myself why I bother, apart from the paycheck.

Not to reiterate the entire rant again, but the gap between the quality of what I can do when I get to choose the tools and what I can do when I don't get to choose is simply mind-boggling.

At the moment, I am too benighted by my thesis to care deeply about the fates of benighted non-academics.