Tuesday, November 29, 2011
An idea: an anti-framework for science
So here's my idea: an anti-framework. I'm interested in the idea of building a framework, because it would be nice to provide a nice, standard set of libraries and modules to work in (much like the standard library, but extended to cover the scientific domain). However, the problem with building frameworks is basically the competing standards problem.
So here's my new idea. An anti-framework, build out of a relatively small number of de facto standard scientific components for Python (like numpy, scipy, matplotlib, I imagine there are some others) and call it something zingy. Any framework or environment which passes its unit tests in the anti-framework is then "zingy-name-compatible". You don't run with a zingy-name framework, because lots of people need more than what's in the standard framework for all sorts of reasons. It's perfectly okay for some-other-framework to extend zingy-name-framework, so long as it remains backwards-compatible with zingy-name framework.
Then, anyone building a relevant application, framework, or whatever can be zingy-compatible if they will support any tool written only using the zingy core libraries.