|
This sounds really good. As a new lisper coming from the C#/ASP.NET world, and I think a lot of adoption lessons can be learned from the .NET framework, which is a mud-ball of epic proportions. One thing that helps developers adopt C# is decent documentation and the availability of sample code. (having it be the only option also helps) I think in order for experienced lispers to adopt a library for a utility function, it just needs be easier to find, install, and use the library than to write the utility function. Having good googleable HTML documentation will make it easier to find utilities, and from the list below, thats in the plan. In order for new lispers to adopt a library, I believe sample code is essential. I think a lot of new lispers are coming from .NET, Java, Python, or PHP, which all have standard libraries and code samples galore. We're used to including massive black-box libraries in our applications and looking up the sample code. I can google many common tasks (eg "php email attachments") and come up with samples of how to do it with C#, Java, Python, and PHP in the first page of results. It helps us a lot to see a function used in context. As a side note, I think some of these goals might overlap with work on http://enterpriselisp.com and http://cl-user.net, and there might be some reuse available. Thanks, Ryan Davis Acceleration.net Director of Programming Services 2831 NW 41st street, suite B Gainesville, FL 32606 Office: 352-335-6500 x 124 Fax: 352-335-6506 Ian Eslick wrote: Great discussion these past two days, let me see if I can capture the input in the form of an updated proposal: Distribution and name space ------------------------------------ My idea was to avoid too much required pollution of the namespace by providing different options for importing library names. We break the library up into multiple conceptually related groups of functions but allow those names to be imported all at once (stdutils.all), by area (stdutils.io, stdutils.math), or individually (stdutils.ctrl.if*). The second problem is polluting your image with a huge amount of code you don't need. Now lisp is so big in most cases that no one is likely to notice, but some folks might want flexibility. So again we have a default model and leave an option for experts. If you release a single tarball and a single asdf entry point you can still break it into subprojects that can be loaded separately (asdf:operate 'asdf:load-op :stdutils.math) vs. (asdf:operate 'asdf:load-op :stdutils) Upgrades polluting namespace. Versioned import will keep the namespace from getting polluted upon upgrades. We should also make it easy to craft your own utilities import so you can write an application-local file that builds and imports just the stuff you need. Lots of little files in the stdutils distribution will make this easier. The standard approach will be that you get all the basic stuff as part of using stdutils but have to import larger packages explicitly. Versioning -------------- While we will try hard to limit the standard library to highly stable and mostly single-function utilities there will undoubtedly be versioning issues as the library evolves, fixes bugs, enhances features and such. However if many people are to depend on it (libc) we should consider a commitment to users on upgrading the library. On the whole, I would support a model where strong argument is needed for changing a function's behavior and that importing a new distribution can be done without changing any existing code but that new functionality can be imported on a per-function basis (import statements) or by switching the use-package to the new global version number. Documentation -------------------- Library has a standard documentation model for how functions are documented. This should enable automatic generation of PDF and HTML for browsing, searching & reference. Decision making --------------------- I find that having a straw man system to explore, critique or patch works better than higher level discussions. I have a local repository where I've already integrated my group's utilities as well as anaphora, selected parts of monkeylib, etc. I have family in town this weekend but would like to release an alpha version of 'stdutils' for people to experiment with and critique late next week or next weekend. If anyone would like to submit something to this initial release, please send me a tarball or a pointer. Would anyone like to volunteer to put together a strawman model of the package versioning we've discussed? (Thanks to Nikodemus Siivola for the draft code!) I should have time to take a pass at it myself but I have alot of other things to do as well so some dedicated effort could go a long way. Ian Pascal Bourguignon wrote: |
_______________________________________________ Gardeners mailing list [email protected] http://www.lispniks.com/mailman/listinfo/gardeners
