Re: Re: dynamics: comment about MBdyn...

On Thu, 17 Jul 2003, Klas Nilsson wrote:

[...]
> We would need no work out more complete examples in detail and have
> discussions around it (when and where is the next orocos workshop?).
The project stops end of August. So, no workshop is planned anymore.
But there still is some money, so if enough people are interested, I
can organise one...

> Basically I
> agree with Michael, and he already expressed many things better than I would
> have been able to do, but the way you two don't quite understand each other is
> kind of typical (experienced also in other cases). We simply have to build
> systems and platforms that permit us together exploring these
> issues/tools/principles.
[...]
> > But "hybrid" systems have changing causalities. And that means that
> > _somewhere_ you have to "solve loops", i.e., to look at a part of the
> > system that is much larger than one single connection between two
> > components in the system, and determine when and how the causality
> > changes. This can be done during parsing, if one has full knowledge
> > about how the system _can_ change; the result is a FSM-like
> > controller, where each hybrid transition results in the execution of
> > the controller in another state.
> > 
> You are right, but wouldn't it be fine to generate that code from a
> declarative description such as Modelica 
Absolutely. That's why I am interested in Modelica. I think it is
still the only formalized and freely available modelling language that
suits those needs.

[...]
> > There are two sorts of bugs:
> > - syntactical: you made a wrong implementation of a correct design.
> > - semantical: you made a wrong design; or a wrong model of the world.
> No, you have to split the implementation bugs in two (or more) cases:
> 1. bugs that result in wrong results or in exceptions (or bugs that
> do not matter).
That's what I call "semantical": nothing crashes, but the results are
wrong.

[...]
> > I think that, almost by definition, you cannot have a "sandbox"
> > security, for either of these bugs, because all components are
> > interconnected and an error (of whatever origin) _will_ influence the other components. That's the essence of a complex system, ins't it? 
> > 
> No, no; this is the most common misconception I know. On the other
> hand we have to be carefule about the meaning of "influence" here:
> Yes, bugs will influence other components, even so that the
> application can fail (complex systems as you point out), but
> error/exception handling and the platform itself will continue to
> work. Thus, with a safe language recovery is meaningful. 

That's the theory, and I am willing to believe you for the practice
also. But how can you be so sure that the correct exception will be
thrown at the correct instant? As far as I know, it's a _programmer_
who has to code exceptions, isn't it? And because complex systems have
complex behaviour _caused by their interaction_, these interaction
"exceptions" are very hard to code right. In any language.
On the other hand, the complex systems we are talking about are only
complex because of their interaction, and not because of the
complexity of their components: these are quite simple, and can get
right by single programmer efforts.

> With an unsafe language, you need so much more engineering (as when
> ensuring that a JVM is correct) to make a reliable system. 
True. But the mistake I see way too often is that people think they
don't have to worry about making good implementations, because their
safe language protects them against anything... :-)
At the end, the quality of your system depends on the quality of the
designers and implementors, and not on the quality of your language.
And, certainly, high-quality implementors using a safe language can
bring you _much_ further :-)


> major applications/components, it could be acceptable, but for orocos it would
> be desirable to have components/interfaces providing Java-APIs 
I think the APIs are so simple and well-understood (basically what is
in Modelica already) that a Java API will be straightforward.
In this stage of the project, I want to discuss the names and meanings
of classes, with the requirement that they should be useable in most
languages. (So, being careful not to use language-specific idioms.)


(but to handle
> real time has been a research issue, so the approach so far is OK).
> > 
> >>>I am really beginning these (by now already) classical Software
[...]
> Well, I'm not that positive to patterns, but I agree. In addition,
> however, a safe laguage simplifies the development of advanced
> developments tool that still permits handwritten code (since there
> is control over what that code can do).  IBM understands that (see
> www.eclipse.org, which is open source).
...and slow :-) And not supporting other languages than Java in a
decent way. (But that will come, no doubt.)

Herman

-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480