[racket-dev] planet2

Jay McCarthy wrote at 12/10/2012 02:22 PM:
> On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke <neil at neilvandyke.org 
> <mailto:neil at neilvandyke.org>> wrote:
>
>
>     * I'm very concerned about discarding support for mixing versions
>     of packages.  PLaneT 1 didn't fully nail this, but I suspect
>     planet2 is punting needlessly, rather than getting data and
>     solving problems (perhaps due to changing mission, as speculated
>     in next two points).
>
>
> My rationale is that what OSes provide is good enough for wide uses 
> and we can more easily build the right versioned package system on top 
> of this than a non-versioned package system on top of one that is 
> versioned.

Perhaps some multiple version support can be grafted on later 
satisfactorily.  I'm just surprised by abandoning the problem, after 
PLaneT made a credible first attempt, and before Racket actually got 
much experience with apps built from lots of independently-developed 
packages.

I still suspect that multiple versions support is a good thing and 
doable.  I wonder whether the design of a new packaging system would 
benefited from having worked through the versioning problem in the 
earlier stages of design, rather than after migrating people from one 
system to a new one.  I don't really know.

> For example, the various library collections on P1 (like scheme, 
> unlib, etc) seems to me a product of the pain of P1 deployment 
> encouraging monolithic packages.

There are also lots of small, loosely-coupled packages in PLaneT.  
Certainly, getting things into PLaneT is tricky, and sometimes, even if 
people got one version into PLaneT, sometimes they'd tell people "a 
better version is in Git" because they didn't want to go through PLaneT 
hoops again.  And there are other reasons people make monolithic 
libraries -- this is not at all peculiar to PLaneT.  Which is part of 
why I was planning in my book to push people to developing around 
loosely-coupled reusable modules, with very low friction to moving the 
module to PLaneT.  I was working on tools to make that a reasonable story.

>     * Related to previous point, it also looks like there *might*
>     (unclear) be a desire to increasingly centralize or canonicalize
>     some of the kinds of library work that I've been thinking are
>     generally best done in a more decentralized and organic manner.
>      If so, have to be careful with this.
>
>
> I assume you are referring to the suggestion to (a) use known 
> collections like data, (b) not give things cute names, and (c) not 
> name things after developers. 

No, it looked like it might be an implicit, pervasive influence.

> This would, for instance, make it so that we have "net/soap" package 
> rather than "roap", "unroap", and "super-soap". I think this is a good 
> thing. We should be encouraging collaboration to produce excellent 
> packages rather than having many 20% solutions.

If one has the resources to pull this off, more power to one.  I'm not 
sure Racket has the resources.  (One way you could do it is if PLT 
Design hired expensive full-time engineers who don't have 
research/teaching commitments.  Or you could do it as projects for 
undergrad team software engineering courses, but I suspect the quality 
of design and implementation would often not be up to what people come 
to Racket for.)

I suspect there's still a big place for grassroots library development 
for Racket.  So I hope the design of the new package system hasn't been 
biased away from grassroots needlessly.

Above are my main points.  Rest of this email is asides, some 
supporting, and some tangential.  All can be skipped.

If you want me to see a response, please CC me.

* * *

Aside #1: On your "net/soap" example... I think a generally better 
practice would be to name it "soap" rather than try to munge a 
conceptual taxonomy into the name as "net/soap", unless "net/" is some 
intertangled framework (which it doesn't seem to be).  The taxonomies 
change over time -- more frequently than the names should.  I think one 
of the PLT lists discussed this before.  Thankfully, people nowadays 
avoid putting these taxonomies as part of the key for most purposes.  
For example, package namespaces for various GNU/Linux distros are flat, 
even if they tend to use taxonomies for UI purposes elsewhere.  For a 
negative example fresh in my mind, CDDB is reviled for using genre as 
part of its key, rather than showing more foresight with their namespace.

Aside #2: Don't be *too* hard on the cutesy names.  Even when projects 
do the officially blessed module with boring name, they tend to wind up 
with better modules arising separate from the official one.  If they do 
eventually move to bring the iconoclast into the fold, blessing it with 
an official generic name, sometimes they tack a "2", "new", "ng", or 
other suffix/prefix onto the old generic name, or sometimes they simply 
break backward compatibility, so you get people talking about which 
version of a language you used for an app when they're really asking 
about which library you used.

Aside #3: Cutesy or developer-qualified names (e.g., Java's use of 
domain name authorities) are also a way for someone to name their 
library and share it, without the burden of trying to be the 
be-all-end-all of "foo".  In his/her spare time, the pope can decide 
whether and when to elevate "fooey" or "joe/foo", or "com.joe.foo" to 
the official "foo".  (I don't actually like seeing my name in package 
names, but I do like that I can comfortably be less cutesy with the 
names, such as when HtmlPrag (an awful name) became "html-parsing" and 
"html-writing", without worrying that I'm getting in the way of someone 
else's better efforts.)

Aside #4: I can tell you that on multiple occasions I've had a client 
want me to revive some old app code, usually written in Python or Java, 
which includes trying to figure out which versions of libraries were 
used originally (and/or port the code to newer versions of the 
libraries, since both Java and Python communities often break backward 
compatibility, and libraries that come through Debian/Ubuntu packaging 
also tend to break at that point, too).  On multiple occasions, at the 
risk of sounding like a fanboy to client, I've used this as an 
opportunity to advocate Racket, noting that Racket does a better job of 
this (with PLaneT).

Aside #5: I'm not sure what the lesson here is, but... the talk of %age 
solutions reminded me of when Olin Shivers said something similar... 
when he put a lot of effort into a couple early SRFIs.  And then the 
SRFI drafts went through a community process for refinement.  And 
PLT/Racket didn't really pick up the result.  And Dr. Shivers directed 
his energy towards other pursuits.  I'm stretching a little, but one way 
to spin this is that canonical library development expensive and 
complicated, and you'll need to enlist and retain enough highly-skilled 
resources if you want it to happen and keep happening.

Aside #6: My coolest libraries (like my time library) are unreleased, 
because I was waiting for them to be sufficiently polished, and then 
they bit-rotted.  And lots of other times, I'm in the middle of an app, 
and don't have time to perfect each of the few of new reusable libraries 
I made in the course of making the app.  So I switched to releasing 
early-and-often (with ugly warnings about known issues), which seems to 
have more net benefit.  I prefer to do complete solutions, but I don't 
have enough resources, and I don't think Racket overall does, either.

Aside #7: We're probably all seeing instances right now when multiple 
different people each probably feel like it might be easier to just do 
things their way, get it done, and move on with their *real* projects, 
rather than to discuss and try to reach some kind of consensus or 
bearable compromise.  Which is sorta how I think libraries are usually 
going to be developed.

Neil V.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/dev/archive/attachments/20121210/e8ffaf06/attachment-0001.html>