> > There are now several projects announced on this list, all of them deal > with > data analysis on one way or the other. Would it be possible to join forces > and merge these projects so that we end up with one library that servers > multiple purposes equally well? Something where the final product is > greater > than the sum of its parts... > > Or perhaps these libraries have aims that are so different from each other > that the only thing they share is a very abstract concept of "table"? >
Yes? It makes complete sense, from a practical perspective, to not duplicate work. Without bikeshedding ("where should the conversation happen?", "what color should the logo be?"), there are easier and harder design constraints. For example, I realized that any sufficiently interesting table interface would, ultimately, embed a copy of LISP... wait... would be a half-assed reimplementation of SQL. So, in my rethink, I just set things on top of the sql library, thus providing the "base language" from which I would work. If SQL can't do it, it's possible I don't need to do it, and it is 100% certain that a first-year, who has been programming for 6 weeks, will not have introductory data questions that cannot be handled by my "target language." Keeping a non-leaky abstraction (or, as non-leaky as possible) that lets a student who is early in HtDP do work with data (in a principled way... another loaded perspective...) is very important to me. I'll trade all the fancy databases in the world (as well as the full expressivity of SQL, and performance for datasets beyond 100K rows, and and and...) for an interface that does a small number of things very well for novices. If we can do our design work so that there are demarked shells of increasing complexity, then yes, I'm confident that we could find ways to combine forces. If nothing else, I'm already eyeing other libraries that I want to "wrap," so that they operate on the substrate I'm laying. I want simplified plotting (with possibly reduced levels of customization from full 'plot', either enforced through interfaces or simply enforced by reducing the documentation for the interface), basic tools for summarizing and analyzing data (I'm thinking of wrapping the "data-science" library that is floating around, but not packaged)... so, yes. I don't want to reimplement everything, but I do need a common substrate. At the moment, I've decided that anywhere Racket runs (and that my students will use it) is powerful enough to also have SQLite, and for my time, energy, and task, there are worse choices than just using SQL. But, back to bike-shedding... at the least, it might be interesting to kick around a set of requirements/wants/needs/desires, and from there think about next steps in design. However, blank-whiteboard design phase work is challenging in distributed/asynchronous modes, so I'm also concerned that a mailing list amongst people who do not know each-other is a hard way to do good design on something nuanced... but, that could just be a failing of mine. Suggestions for "next steps" on collaboration are something I'm absolutely open to. At the end of the day, I need tools for next Fall (ideally, sooner, so I can begin developing course materials); that's a hard, non-optional design/implementation deadline, no matter how much interest and goodwill there is to collaborate. Cheers, Matt -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.