A friend of mine from MIT who is just finishing his PhD was over for dinner tonight. We discussed the learning curve of matplotlib and compared it with other plotting systems that we've both used, including gnuplot & PyX.
My friend said that he thought that the learning curve was really high, but that he had been motivated to do something with it, so he had persevered. He wasn't entirely happy with what he got, but it was okay. He co-author on a paper, though, couldn't figure it out and thought that it wasn't worth the effort. Interestingly enough, Crossroads, the ACM student publication, had a really interested article on this in the Summer 2006 issue. The article, by Christopher Scaffidi, is titled "Why Are APIs Difficult to Learn and Use?" I would recommend it to anyone who is developing an API or a package. You can read it at http://www.acm.org/crossroads/ xrds12-4/difficultapis.html. The gist of the article is that documentation is extremely important, after which "hello world" programs can be helpful. However, it's really important to have an API that is orthogonal and has the right abstractions. One of the things that I would have added to the article is the importance of having decent defaults. I'm very interested in putting together a document that would be incorporated into the user's manual that would describe the abstractions used by matplotlib. I think that this would help me to understand it better, and would also be useful to the community. Does anything like this currently exist? To answer Eric's most recent posting: 1. I think that scientific notation should not be the default, unless numbers exceed 1E+7. 2. It would be nice if there was an easy way to get commas into numbers. (This is forever a problem; I wish that the original C folks had thought to put commas into their original printf formatting. I have a nice python commas function if you want it, although you can probably create one that is more efficient.) 3. If I was going to make a major change to the API at this point, it would be to make it so that you don't have a class/function/ identifier called "axes" and another one called "axis." I frequently get confused between these two words; I imagine that non-native English speakers get confused even more frequently. Irregular noun plurals in English are confusing, and it probably isn't necessary to use both. One approach would be to never allow "axis," to only allow "xaxis" and "yaxis" and perhaps something (either_axis?) for the abstract super-class, but this may be a bigger change than you wish to consider at the present time. > It may make sense to have a simpler interface to this--especially > simply turning scientific notation on or off on one or both axes-- > at the Axes class level and the pylab level, but I thought I would > take it a step at a time. I am open to suggestions as to method/ > function name and signature. The matplotlibrc interface could even > be used if people really want to be able to make no-scientific- > notation their default, but I am wary of dumping more and more > knobs into matplotlibrc. Ah, the matplotlibrc file. It seems that you are trying to do too much with this file. Is the point of the file to have default graphing behavior, or to have site-wide configuration information? You may wish to split the file into two parts --- a config part and a graphing preferences part --- because it seems that sometimes people wish to change one without changing the other. Or you may want to have explicit inheritance --- like an "-include" feature so that a local file can just shadow some variables and then include the master file. I understand that this can be done with a few lines of python at the top of a program. Of course, given that option, you may wish to do away with the local files entirely. I'm not sure. Have the matplotlib developers put together a roadmap of their directions that they want to take this project? -Simson ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Matplotlib-users mailing list Matplotlib-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/matplotlib-users
