Re: [SED-ML-discuss] Future of SED-ML

[Andrew M. <ak....@au...>]

On 20/01/12 11:39, Frank T. Bergmann wrote:
>> I don't think anyone has made a convincing argument for reinventing the
>> wheel to create this domain-specific programming language.
>
> I would argue, that we are not re-inventing the wheel. What we are doing is
> creating a language independent specification of simulations.

If we are creating a new language to describe simulation procedures 
imperatively, it isn't language-independent - it is dependent on the new 
language we invent (you wouldn't be able to describe your simulations 
independently of the new 'nested simulations' language).

> That way it
> can be re-used in *any* language, at *any* time. Encoding the same protocol
> in  imperative code has several obvious drawbacks:
>
> 1. we would need to choose a language (and this will be a hard one to agree
> about)

There are far fewer decisions to make in picking an existing language 
compared to designing a new language from the ground up, because the 
existing languages have already taken these decisions and their 
respective communities have already come to consensus on them.

> 2. we would then *all* need to somehow embed this language in our
> applications (or use interop) / or write our own parsers for that language
> so we could adapt it in other languages

This same argument applies equally to a newly created nested simulations 
language, except that a newly created language will have a far smaller 
base of existing code to try to interoperate with.

> 3. we would be at the whim of the language designers (look what happened to
> python with v3 and compatibility to previous modules)

We could declare that the language to use is a particular version of the 
existing language. In terms of change control this would put us in an 
identical position to reinventing the wheel - if we don't do anything 
explicitly, the language doesn't change - but we would have a much 
better language available with a lot less work.

> 4. we would lose the capabilities for annotation that we currently have.

I'm not sure how you would annotate the imperative parts of a nested 
simulation anyway - it is essentially a black box, where you annotate 
the inputs and the black box as a whole, but not the internals of the 
black box. Likewise, if we embedded an existing imperative language, it 
would similarly be treated as a black box where you would annotate the 
inputs and the black box as a whole, but not individual instructions in 
the black box. If we allowed black boxes to refer to 'functions' defined 
other black boxes, you could still break up the imperative code into 
several blocks, and annotate those blocks separately.

>
> We have SED-ML now so I would be in favor of using it. It has taken us
> already 4 years to get to this point.

SED-ML is a purely declarative description; there is a clear place for 
something like that.

What we are talking about now can be thought of as a way to describe how 
different types of simulation experiments are performed, as opposed to 
just declaring the simulation experiment.

> I don't see that splitting the
> language into two separate ones is aiding our cause.

We are trying to do two slightly different things. Perhaps an 
alternative would be to at have least two different parts under the same 
specification for these things (declaring a simulation in terms of 
simulation types, and defining a simulation type); this would be 
analogous to what the W3C did with MathML, where both content and 
presentation MathML are described in a single specification.

> Neither would be us
> arguing about choosing another representation layer by moving away from XML.

We wouldn't have to move away from XML - we could embed fragments of 
another language in XML as a CDATA section.

Best wishes,
Andrew