>
> 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.
