NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
Hi Frank, > I just wanted to add my voice in support of Maohai Huang's suggestions: > . . . > Like me, they are looking for a library > that will allow them to do what they need to do quickly and easily, > probably starting with some kind of 2D graph. If VisAD allows them to do > that, through a set of wrappers that hide the complexity (and I'll admit > that JyVisAD goes some way towards doing this - Tom Whitaker's graph/subs > modules do hide a lot of the complexity - but it seems like an > afterthought, rather than an integral, serious part of VisAD development), The easy Python interfaces are an afterthought, in the sense that they are built on top of a much more abstract layer. That abstract layer puts people off, but it is also the necessary basis for generality and flexibility. > then perhaps when it comes time for them to do more serious visualization, > they will have gained familiarity with VisAD enough that they'll be able to > tackle something more complex. By having the learning curve so steep, you > keep out all but the most committed, hard-core Java programmers. Certainly, > VisAD appears to be written to be correct and generic by design. But what's > wrong with putting in a gentle on-ramp? As Maohai said and I agreed, the major requirement here is documentation. I think that Ugo's tutorial is an excellent start, as well as the tutorials Tom has written. And we would really like you and other folks to contribute documentation that solves the problems you see with the current documentation. > . . . > Perl/Python have a mantra: "Simple things should be simple to do, difficult > things should be possible." Part of Perl's success is that it allowed > people to do things quickly and easily, which up till then had been > difficult and time-consuming. Python allows that too, and in a way that is > readable to people other than the original programmer ;). Why can't VisAD > take the same approach? I know that mantra well and strive for it in VisAD. The abstract generality are there so it can make "difficult things should be possible", and the Python interface is there to make "Simple things simple". In addition to documentation, we also want people in the community to contribute libraries of Python functions that make smple things simple. I think Tom has a very good start on this. The bottom line is that VisAD is an open source project that depends on the contributions of people in its community. Cheers, Bill
visad
archives: