On Thu, 13 Feb 2014, S Roderick wrote:

> On Feb 11, 2014, at 05:54 , Herman Bruyninckx <Herman [dot] Bruyninckx [..] ...> wrote:
>
>> On Tue, 11 Feb 2014, Ruben Smits wrote:
>>
>>> Hi all,
>>>
>>> More recent compilers seem to have problems with the TreeElement
>>> definition: see
>>> https://github.com/orocos/orocos_kinematics_dynamics/pull/4 for more
>>> information. There seems to be no easy way to fix this without an API
>>> change.
>>>
>>> I'm currently trying to get an estimate of the impact of this change
>>> for our users-base. I know the Tree structure and its solvers are less
>>> used than the Chain variants but I still would like to query the
>>> community to see if anyone would object a merge of the pull request.
>>>
>>> It is still open if we will use plain pointers or shared pointers.
>>>
>>> So if anyone objects with the pending API change or has a more elegant
>>> solution, please speak up.
>>
>> My two cents...
>>
>> I think (hope...) that the robotics community has bounced its head enough
>> times against the wall, hard, to have learned that "exploiting" "advanced"
>> C++ features is not the most maintainable way to go...
>
> The problem here was use of a well known and well accepted C++ approach
> (which actually derives from a standard C approach), which a newer C++
> standard outlawed (perhaps rightly so). There is nothing advanced about
> the technique used, nor was it "exploited" in any sense.

My remarks go quite a bit further than this particular issue in this
particuler thread :-) Sorry if that caused confusion, or irratation.

>> Hence, I fully support an API change, and a drastic one, namely making KDL
>> into a plain C library, all the way through. For the following reasons:
>> - maintainability: the semantic differences between C compilers is an order
>> of magnitude less than for C++;
>
> The difference between C++ compilers has no bearing here; that's a
> specious argument. This is a standards issue, and KDL has run into the
> problem on the first compilers to adhere to the new standard. In time,
> all modern compilers will adhere to the standard and then all these
> compilers will have the same issue. And in my experience, having multiple
> compilers is a good thing as they do help to find more issues.

The semantics of the _runtime_ that different compilers generate is not
fully standardized, and these things cause uncertainty in the exact
realtime performance. This is not a problem for most features, but things
like exceptions will remain unpredictable between compilers. At least, if I
understand the technology correctly...

>> - clarity of the code: much of the Eigen and Boost stuff is hiding
>> behaviour (especially realtime) opaquely behind interfaces with side
>> effects;
>
> Can you provide some examples of these "side effects"? I agree that Eigen
> and Boost can hide stuff, but I would also bet no one on this ML can
> write as optimized a code as Eigen has, particularly on multiple
> platforms; if you want performance, that's a definite example were
> template black magic can achieve some utterly amazing things.

I want code whose semantics can be understood, ultimately, by robots, and
not just by compilers. I know that this sounds a bit extreme in a "hackers"
community, but the more "intelligence" one wants to bring into a system,
the less one want to rely on compiler "features" to support that.
Templates and exceptions are two examples of necessary aspects of
intelligent behaviour, and these are exactly two aspects for which
compilers hide the exact behavioural semantics inside the runtime.

>> - platform support: the future is for mixed-hardware systems, where parts
>> of the functionality will have to run on "accelerated" hardware, such as
>> GPUs or FPGAs, embedded or not in the same System-on-a-chip; C is ready for
>> that ambition, C++ isn't;
>
> That's a very broad statement Herman. Yes, mixed-hardware systems are
> becoming more common, but it can take an extraordinary amount of
> knowledge and experience to do co-design, let alone the skills to write
> good FPGA code.

The FPGA tools are extremely good, a lot better than what mainstream
hackers are used to. And their quality comes exactly from a _very_ deep
level of _modelling_ of all platform aspects ("bus", "ram" and "cpu") which
is almost completely absent in our C++ compilers.

>> - the correctness-at-build-time tests (which are a valid design motivation
>> in themselves!) can also be taken care of with _tooling_, that is
>> completely programming language agnostic, and works on a _formal model_ of
>> the to be constructed primitives, in casy kinematic trees;
>
> How does this not apply to C++ code?

Take templates as an example: they are a "poor man's version" of
Model-Driven Engineering. With the emphasis on "poor"... They are just one
of the examples where compilers (which are "abstract syntax tree"
processors) try to become "reasoners" (which requires "context-dependent
language processing"). It was fine for the first steps, but now compilers
(or rather, hackers that think they should get the last bit of juice out of
those compilers, just because they can) are holding back progress in
introducing models into our code development. And libraries like STL are
doing the same: they force the majority of developers in patterns that are
not the most optimal one for the large variety of problems in robotics. The
story of KDL solvers has been mentioned here multiple times already...

>> - the step toward formal models will be _necessary_ anyway, if we ever hope
>> to be able to support intelligent robot systems, that can check and
>> create for themselves the kinematic chains they have to work with;
>
> How does C vs C++ come into this?

C++ offers tools that basically should be done by dedicated model
transformation tools: templates, exceptions, closures, functional
programming,...

>> - the current KDL API is too limited anyway to deal with the variety of
>> 'sensori-motor control' requirements that modern robots can/should
>> support, as is proven, for instance, by the API explosion for the various
>> forward/inverse/hybrid kinematics/dynamics solvers for kinematic chains
>> that people have contributed already, or are interested in having.
>
> So maybe that argues for a restructuring of the design, but that is not
> necessarily tied to any particular language.

That is exactly what my intention is: to reduce the usage of programming
languages to the things that are not tied to any particular language; which
means more or less that one reduces them to "C"... :-)

>> To put things in a somewhat broader context: robotics, computer vision and
>> machine learning are the only engineering domains where the mainstream of
>> the community has locked itself in into C++. The other domains stick to C,
>> and spend their useful development time in tooling.
>
> Sorry, Herman, but that just isn't true. I have plenty of peers in
> non-robotics engineering fields using C++, Python, Ruby, etc., as well as
> peers in the robotics field using Python, Ruby, etc.

Are you talking about _industry-driven_ software developments, that end up
in high-reliability systems? I am thinking of cars, airplanes, litography
machines, medical instruments,...: _all_ the companies active in those
sectors and that I have some sort of access to are relying on MDE tools for
almost everything.

> I am definitely against reverting to a purely C-based API. It will mean
> writing your own code for things like containers, which are well provided
> and well understood in C++'s STL. And in my experience C++ compilers are
> stricter than C compilers, which helps to find more issues at compile
> time.

Why would you have to write your own code for containers...? All one needs
is a C library that does it well, and preferably has a formal model of what
the code is doing.

> I'm sure that Herman will disagree ...

I do not disagree with your statement that you are "definitely against
reverting to a purely C-based API": everyone is entitled to his/her own
aberrations :-)

> YMMV

Indeed. And my ambition is to (help people) travel more software miles than
what the mainstream robotics coder is thinking about... :-)

> S

Herman