RE: Modelica Conference 2002

[...]
> > > Do you mean for doing embedded system code generation?  Are you
> > > talking about logical control or continuous behavior.  
> > 
> > I'm talking about the dynamics algorithms of robots, to be used by the
> > on-line controllers. Preferably with the ability to switch control
> > laws on-line, which is needed, for example, for controlling a walking
> > robot (during subsequent phases of a step).
> 
> Would the combination of Petri nets and continuous equations be sufficient?

Who am I to predict the future :-) It would certainly be a start I
would be _very_ happy with. As far as I know the state of the art,
there is not yet a clear vision about what is needed exactly and for
what purpose.

[...]
> > Okay, but just calling things by another name doesn't bring us any
> > further :-)
> 
> Just to be clear, I'm not just calling something by a different
> name.  There are real semantic differences.  You wouldn't call an
> XML file just a "text file" right?  It has a specific syntax and the
> content is hierarchically structured.  Annotations are nearly
> equivalent to XML in spirit.  They are "structured meta-data"
> associated with objects, class and connections.

I agree with this. But their syntax remains incompatible to anything
else, so tools will lack.

[...]
> Modelica already contains blocks for both continuous and hybrid
> control.  I would imagine that you would probably want to use this
> in conjunction with something like petri-nets or statecharts in
> order to implement constantly changing control laws.  The demo
> version of Dymola includes the petri net libraries
> (ModelicaAdditions.PetriNets), some discrete controllers
> (ModelicaAdditions.Blocks.Discrete), continuous controllers
> (Modelica.Blocks.Continuous) and some multi-body models
> (ModelicaAdditions.MultiBody).
> 
> While the Dymola tool is proprietary, the contents of these
> libraries are all open source.  You might also be able to download
> them from the web site (http://www.modelica.org).

Don't worry, I did this already a long time ago :-)

[...]
> > That's the reason why I like XML: it's never a monolithic thing, not
> > because of its inherent properties, but because there are so many
> > tools available to transform from and to XML.
> 
> Fair enough.  The difficulty I see with XML is that while you have
> lots of tools, you still need to go to all the trouble of iterating
> over the definitions of schemas and (more importantly) semantics of
> the specification.  Do not underestimate how long this will take.
> They question is, is it really worth it do (re?)do all that?

I think our conversation has all pros and cons together :-) The real
questions have been asked, the arguments are clear, now we ``just''
have to decide how to proceed :-) Since I won't have the time to start
these activities myself in the enar future, I will have to contend
myself by criticising other people's efforts :-)


[...]
> Modelica has a strong type system.  Because you can define your own
> connectors, you can pretty much make sure that nobody hooks up
> anything that is incorrect.

Indeed, and that's the major reasons I consider Modelica as a
_potential_ universal language. What keeps me from being enthusiastic
is that I see no decent and modern software engineering behind it. I
mean, where is the ``component--object''-based documentation and
vision on the corresponding software? I dream of a component-based
system description, with ``real components'' in the software
engineering sense of the words. Call them CORBA or .NET components, if
you like. Modelica is a ``C oriented'' design. Which is not bad in
itself, but it's time to do better :-)

Herman