<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body text="#000000" bgcolor="#ffffff"> Jay McCarthy wrote at 12/10/2012 02:22 PM: <blockquote cite="mid:CAJYbDamwS2acJ+tN-KvL+XTACYb6GNomybJxEx_9ikpheGCaDA@mail.gmail.com" type="cite">On Sun, Dec 9, 2012 at 1:26 PM, Neil Van Dyke <span dir="ltr"><<a moz-do-not-send="true" href="mailto:neil@neilvandyke.org" target="_blank">neil@neilvandyke.org</a>></span> wrote:<br> <div class="gmail_extra"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br> * 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).<br> </blockquote> <div><br> </div> <div>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.</div> </div> </div> </blockquote> <br> 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.<br> <br> 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.<br> <br> <blockquote type="cite">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.</blockquote> <br> 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.<br> <br> <blockquote type="cite"> <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">* 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.<br> </blockquote> <div><br> </div> 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. </blockquote> <br> No, it looked like it might be an implicit, pervasive influence.<br> <br> <blockquote type="cite">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.<br> </blockquote> <br> 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.)<br> <br> 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.<br> <br> Above are my main points. Rest of this email is asides, some supporting, and some tangential. All can be skipped.<br> <br> If you want me to see a response, please CC me.<br> <br> * * *<br> <br> 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.<br> <br> 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.<br> <br> 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.)<br> <br> 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).<br> <br> 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.<br> <br> 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.<br> <br> 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.<br> <br> Neil V.<br> <br> </body> </html>