On Mon, Mar 2, 2009 at 3:52 PM, Gael Varoquaux <
gael.varoqu...@normalesup.org> wrote:
> On Mon, Mar 02, 2009 at 01:49:38PM -0600, Ryan May wrote:
> > Other than the automatic regeneration from latex, what you want sounds
> > like what we already have: small python scripts.
>
> > In general, I'm completely amazed by how many people want to develop a
> new
> > markup/script language to wrap what is already a simple and expressive
> > language, both for plots and (at least around here) analyses. If
> there
> > are some spots that require too many lines of code to accomplish
> something
> > really simple, then maybe we need to API additions. But in general, I
> > think we have a format for specifying how to make a plot: python.
>
> Although I agree with you that reinventing an extra scripting layer is
> often a bad solution to a problem which should simply be solved by having
> a good scripting API in Python, I believe there is here a fundamental
> misconception.
>
> Python is an imperative, Turing-complete. This is a very good thing for a
> scripting language. For making a description of a static object as a
> plot, this is not a good thing. For instance, if I want to make a plot,
> save it, and later blow up all the fonts, I really don't want to be using
> an imperative, Turing-complete language for the persistence model, as
> static analysis of this persisted object is going to be next to
> impossible. Same thing if I want to change colormaps, or just about
> anything in my persisted object, for the same reason.
>
> A good rule for most software design is that the state of the
> application, or of the object of interest, in our case the plot, should
> be fully represented by a fully-static set of values, that I like to call
> the model. Although this sounds like a tautology, this design rule is
> more often broken than followed. For instance the status of an
> application may be entirely dependent on its past, or the important state
> variables may be hidden in places where you can't get hold of them (eg
> the status of a GUI widget, or inside a generator).
>
> Having a very clean separation between your (fully-static) model, and the
> logics around is a very important part of good application design, and I
> believe I know this because I have so often made an error and violated
> this rule :).
>
> If you have this static model, rather than an imperative language, then
> you can have persistence. By the way, Mayavi2 achieves its code
> generation by introspection on the model. The generated lines of code are
> just a way of expressing the changes.
>
> Sorry for being fussy, I am just trying to pass on what I believe I am
> learning painfully :).
>
Not at all. You made some good points. I hadn't really thought about the
prospect of things changing in the core of the rest of the code. It was
probably just a knee jerk reaction to something I hear a lot around here,
regarding making a small language/configuration file for automating analyses
*in python*. :)
Ryan
--
Ryan May
Graduate Research Assistant
School of Meteorology
University of Oklahoma
Sent from: Norman Oklahoma United States.
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
